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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The 3GPP Packet Switch Streaming (PSS) provides a framework for Internet Protocol (IP) based streaming applications 
in by specifying protocols and codecs within the 3GPP system. Protocols for control signalling, capability exchange, 
media transport, rate adaptation and protection are specified. Codecs for speech, natural and synthetic audio, video, still 
images, bitmap graphics, vector graphics, timed text and text are specified. 

The 3GPP Multimedia Broadcast and Multicast Service (MBMS) provides a framework for broadcast and Multicast 
streaming and download applications in 3GPP networks supporting the MBMS bearer service. The MBMS user 
services are enabled by a set of specified media codecs, formats and transport/application protocols. MBMS user 
services are built on top of the MBMS bearer service. There are two delivery methods for the MBMS user services: 
download and streaming. 

The 3GPP IP Multimedia Subsystem (IMS) enables the deployment of IP multimedia applications. PSS and MBMS 
User Services are IP multimedia services but they were specified before IMS. IMS brings enablers and features to 
operators and subscribers that can enhance the experience of PSS and MBMS User Services. 

The purpose of the present document is the specification of use of the IMS to initiate and control PSS and MBMS User 
Service. This should enable deployment of PSS and MBMS user services as IMS services. Note that the present 
specification uses components of the 3GPP PSS, 3GPP MBMS , ETSI TISPAN IPTV and Open IPTV Forum standards 
specifications. 
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Scope 



The present document specifies the usage of IMS protocols to initiate and control PSS and MBMS Streaming and 
Download User Services based applications. It applies to IMS enabled UEs that also implement PSS and/or MBMS 
clients. Existing protocols that are used are described in reference to relevant specifications. 

The present document is applicable to IP-based packet-switched networks over 3GPP systems. 

The present document includes information applicable to network operators, service providers and manufacturers. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

On Demand: users can select their required content, for example with the assistance of the Electronic Programme 
Guide (EPG), at the user preferred time. 

NOTE: The content is then transmitted uniquely (unicast) to that consumer who can usually use trick-modes 
functionalities to control their viewing of the content, e.g. TV Content on Demand (CoD) 

IMS registration: registration procedure for a public user identity initiated by the UE in the absence of any valid 
registration 

Live: content is streamed and intended for reception by anyone where the consumer has no control over the content or 
timing of what he receives, apart from the ability to select a particular channel, e.g. linear TV. 

"Non-IMS" BM-SC: BM-SC function as defined in 3GPP TS 23.246 [5] and 3GPP TS 26.346 [11] without any IMS 
support 

Multimedia Broadcast/Multicast Service (MBMS): See 3GPP TS 22.146 [2]. 

MBMS User Services: MBMS User Service may use more than one Multimedia Broadcast/Multicast Service (bearer 
service) and more than one Broadcast and/or Multicast session 
(See 3GPP TS 22.246 [3].) 

MBMS user service discovery/announcement: user service discovery refers to methods for the UE to obtain the list of 
available MBMS user services along with information on the user service and the user service announcement refers to 
methods for the MBMS service provider to make the list of available MBMS user services along with information on 
the user service available to the UE 

MBMS delivery method: mechanism used by a MBMS user service to deliver content 

An MBMS delivery method uses MBMS bearers in delivering content and may make use of associated procedures. 

MBMS download delivery method: delivery of discrete objects (e.g. files) by means of a MBMS download session 

MBMS streaming delivery method: delivery of continuous media (e.g. real-time video) by means of a MBMS 
streaming session 

MBMS streaming session: time, protocols and protocol state (i.e. parameters) which define sender and receiver 
configuration for the streaming of content 

PSS client: client for the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP 
standards, with possible additional 3GPP requirements according to the present document 

PSS server: server for the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP 
standards, with possible additional 3GPP requirements according to the present document 

Trick Play: streaming playback mode during which the user can control playback by playing, seeking, pausing, fast 
forwarding and fast rewinding 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply: 

BM-SC Broadcast-Multicast - Service Centre 

CoD Content on Demand 

ESG Electronic Service Guide 

GGSN Gateway GPRS Serving Node 

IMPI IMS Private Identity 
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IMPU IMS Public Identity 

IMS IP Multimedia Subsystem 

lUT Inter UE Session Transfer 

IP Internet Protocol 

MBMS Multimedia Broadcast/Multicast Service 

PSS Packet Switch Streaming 

PSI Public Service Identity 

RTP Real-Time transport Protocol 

RTSP Real-Time Streaming Protocol 

sec Service Centralization and Continuity 

SCF Service Control Function 

SDF Service Discovery Function 

SDP Session Description Protocol 

SSF Service Selection Function 

UE User Equipment 

URI Uniform Resource Identifier 

USD User Service Description 



System description 



4.1 



Introduction 



This clause describes the IMS initiated and controlled PSS and MBMS User Service system. It gives a description of 
the architecture, the role of each new and modified entity and interface. 

The description of the PSS system is in 3GPP TS 22.233 [9] and 3GPP TS 26.233 [10]. The description of the MBMS 
system is in 3GPP TS 23.246 [4]. 



4.2 



Architecture 



4.2.1 Non IMS 3GPP PSS and MBMS User Service architecture 

Figure 1 describes the Non IMS PSS and MBMS User Service architecture. 

Unicast/Multicast/Broadcast Bearers 



PSS and 
MBMS client 
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Live encoders, 

On demand RIes 
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PSS server 




\ 














/ 


BM-SC 

















Figure 1 : Non IMS PSS and MBMS User Service Architecture 

The sources consist of all multimedia content in streaming or file form. E.g. live encoders processing in feeds from TV 
or Music Radio channels. 

The PSS server performs control and streaming delivery functions on a Unicast access type. 

The BM-SC performs control and streaming/download delivery functions in a hybrid Unicast/Multicast/Broadcast 
access type. 
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The core network and RAN enable the mobility, and provides IP connectivity over Unicast/Multicast/Broadcast bearers 
between the servers and the clients. 

The PSS & MBMS client, located in the UE, performs service selection and initiation, receives and present the content 
to the user. 

The PSS client interfaces to the PSS server transparently through the Packet Switch Network. The PSS client can 
discover the PSS services via multiple means like e.g. browsing. The session description protocol is SDP. The session 
control protocol is RTSP. The transport protocol is RTP. 

The MBMS client interfaces to the BM-SC via layer 3 protocols defined between the UE and the GGSN and the GGSN 
with the BM-SC (Gmb). 

The PSS and MBMS client interfaces via the Radio interface to the RAN and the CN. 

The interface between the sources and the PSS server & BM-SC are outside the scope of the present document. 

4.2.2 IMS based PSS and MBMS User Service architecture 

Figure 2 describes the IMS based PSS and MBMS User Service functional architecture. In addition to PSS and MBMS 
User Service functions, the IMS core and various functions are added. 
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Figure 2: IMS based PSS and MBMS functional architecture 

In figure 2: 

• Solid lines are standard interfaces. E.g. interface between PSS server and UE4. 

• Dotted lines are for interfaces for which the protocols in use is out of the scope of the present document. 
E.g. interface between SSF and BMSC.UPF. 

Description of functional entities: 

• IM CN Subsystem: IMS Core Network Subsystem as defined in 3GPP TS 23.228 [6]. The IM CN Subsystem 
supports, user registration and authentication, mobility and roaming, control of multimedia sessions, QoS 
control. Policy control, charging and interworking with circuit switched. 

• EPC/PS Core/RAN: Evolved Packet Core, Packet Switch Core Network and Radio Access Network. See 3GPP 
TS 23.060 [16] and TS 23.401 [30]. 

NOTE 0: the various packet core networks may offer different levels of support (e.g. the EPC does not support 
MBMS in 3GPP Release 8). 
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• UE: The UE contains an GBA/IMS/PSS/MBMS client, which performs service discovery and selection, handles 
service initiation, modification and termination, receives and present the content to the user. In addition to the 
procedures specified in this document, the UE shall support the procedures specified in 3GPP TS 24.229 [7] and 
3GPP TS 24.109 [22] for the UE functional entity. 



• 



• 



SDF: Service Discovery Function (SDF): this function provides an entry point to SSF for the client to attach to 
the service provided by the service provider. In addition to the procedures specified in this document, the SDF 
shall support the procedures specified in 3GPP TS 24.229 [7] for the terminating UA functional entity. 

SSF: Service Selection Function (SSF): this function provides a list of available PSS and MBMS User Services 
and relevant User Service Description information. It can be personalized to the client's identity. The SSF shall 
support Service Announcement functions according to the Xa interface in TISPAN. The PSS portal is for 
formatting and delivery of PSS Service Description information. The BMSC.IAF and BMSC. USD/A functions 
are according to 3GPP TS 26.346 [11]. The interface between BMSC.IAF and UE is according to 
3GPP TS 26.346 [11] and out of the scope of the present specification. If the User Service Description 
information exists in a BMSC.USD/A of a "Non-IMS" BM-SC, or in a PSS portal, the SSF takes USD 
information from them. The SSF may then reformat the USD information before delivery to the UE. The 
reformat may include information for the IMS UE to build a SIP URI to initiate PSS and MBMS user service. 

SCF: Service Control Function (SCF): it provides service logic and functions required to support execution of 
such logic. It does service authorization during session initiation and session modification, which includes 
checking PSS and MBMS user's service subscription in order to allow or deny access to the service. It selects the 
relevant PSS and MBMS media functions. In addition to the procedures specified in this document, the SCF 
shall support the procedures specified in 3GPP TS 24.229 [7]: 

• For PSS, the SCF acts as a proxy or B2BUA. 

• For MBMS, the SCF acts as a terminating UA. 

BSF: Bootstrapping Server Function (BSF) as defined in 3GPP TS 33.220 [26] and 3GPP TS 24.109 [22] to 
perform GBA/GAA procedures with the UE. The BSF supports procedures defined in 3GPP TS 33.220 [26] and 
3GPP TS 29.109 [x] with the HSS and the BMSC.UPF (see clause 10.4.1) and with the HSS and the SCF (see 
clause 10.4.2) to enable GBA/GAA procedures. 

• HSS: Home Subscriber Server as defined in 3GPP TS 23.002. Contains the IMS User Profile and optionally the 
GBA User Security Settings (GUSS) defined in 3GPP TS 33.220 [26] and 3GPP TS 29.109 [33]. It also may 
contain PSS and MBMS User Service specific User and UE data. 

• PSS Adapter: this function performs bi-directional protocol translation between SIP and RTSP to offer control of 
PSS servers as defined in clause 8.2.3.5. It proxies RTSP messaging from the UE and SIP/RTSP translation 
towards the PSS server. Note that these functions can be incorporated into the SCF, the PSS Server or a new 
stand-alone entity. In addition to the procedures specified in this document, the PSS Adapter shall support the 
procedures specified in 3GPP TS 24.229 [7] for the terminating UA functional entity. 

• HTTP/SIP adapter: this function correlates SIP session with HTTP incoming requests. In addition to the 
procedures specified in this document, the HTTP/SIP adapter shall support the procedures specified in 3GPP TS 
24.229 [7] for the terminating UA functional entity. 

• PCRF: Policy and Charging Rules Function (3GPP TS 23.203 [12]). This function controls the charging and the 
establishment of resources in the RAN and PS core network. 

• PSS Server: Packet Switch Streaming server function as described in 3GPP TS 26.234 [8]. It functionally 
contains media control and media delivery functions. 

• HTTP server: this function is described in 3GPP TS 26.234 [8]. 

• BMSC.UPF: it contains all BMSC User Plane sub-functions. 

NOTE 1: The BM-SC Membership function and Proxy and Transport function are defined in 3GPP TS 23.246 [4]. 
These functions are not described on the architecture in figure 2. The BM-SC Membership function is 
invoked for the establishment and release of Multicast bearers. 

Description of interfaces: 
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The interface between the UE and the SSF is used to retrieve service selection information. It is part of the SGi/Gi 
interface and based on HTTP protocol. 

Gm: This is a SIP based interface between the UE (IMS Client) and the P-CSCF. It is used to forward the SIP service 
request and response between UE and network. 

The interface between the UE (PSS Client) and the PSS Adapter allows media flow control. It is part of the SGi/Gi 
interface and based on RTSP protocol. 

The interface between the PSS Server and the UE is for deUvery of streaming data. It is part of the SGi/Gi interface and 
based on RTP and RTCP protocols. 

The interface between the HTTP server and the UE is for delivery of download data. It is part of Sgi/Gi interface and 
based on HTTP. 

The interface between the BMSC.UPF and the UE is for delivery of streaming data and traffic keys. It is part of the 
SGi/Gi interface and based on (S)RTP, FLUTE and MIKEY protocols. 

Gmb: This interface is between the BMSC.UPF and the GGSN. The Gmb interface is defined in 3GPP TS 23.246 [4]. 

The interface between the PSS Adapter and the PSS Server allows control of the PSS Server. This interface is based on 
RTSP protocol. 

NOTE 2: This interface needs to be named. 

The interface between the HTTP/SIP adapter and the HTTP server is based on HTTP. 

The interface between the IM CN subsystem and the SCF is an ISC (IMS Service Control) interface based on SIP. The 
interface between the IM CN subsystem and the PSS adapter is an interface based on SIP protocol.. Both interfaces are 
used to setup, modify and teardown PSS sessions. 

NOTE 3: Under certain conditions this interface between the SCF and the PSS adapter can be implemented as a 
direct interface (i.e. not going via the IM CN subsystem). 

NOTE 4: The interface between the IM CN subsystem and the PSS adapter needs to be named. 

The interface between the IM CN subsystem and the SCF is an ISC (IMS Service Control) interface based on SIP. The 
interfaces between the IM CN subsystem and the HTTP/SIP adapter is an interface based on SIP. 

NOTE 5: Under certain conditions this interface between the SCF and the PSS adapter can be implemented as a 
direct interface (i.e. not going via the IM CN subsystem). 

This interface between the SSF and the BMSC.UPF is according to 3GPP TS 26.346 [1 1]. It may be used to carry USD 
over MBMS bearers. 

The interface between the SDF and the IM CN subsystem is an ISC (IMS Service Control) interface based on SIP 
protocol. 

The interface between the UE and SCF is used for PSS and MBMS User Service and User Profile configuration. It is 
equivalent to the Ut interface in TISPAN IPTV. 

The interface between the SCF and the BMSC.UPF is used for security related functions (see clauses 10.4.1 and 10.4.2, 
respectively). 

The interface between the SCF and the PSS Server is FFS. 

The interface between the UE to the BMSC.SnTF is used for MBMS Associated Delivery procedures as defined in 
3GPP TS 26.346 [11]. It is part of the SGi/Gi interface. 

The interface between the UE and the BMSC.KF is used for delivery of the MSK as defined in 3GPP TS 33.246 [5]. It 
is part of the SGi/Gi interface and based on MIKEY/UDP protocols. 

The interface between the UE and the BMSC.KF may be used for Key Request Functions (see clause 10.4.1). 

The interface between the BSF and the UE is part of the Ub interface defined in 3GPP TS 33.220 [26] and 3GPP TS 
24.109 [22] and used for security functionalities. 
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The interface between the BSF and the HSS is part of the Zh interface to fetch the Authentication Vectors (AV) and 
optionally the GBA User Security Settings (GUSS) and defined in 3GPP TS 33.220 [26] and 3GPP TS 29.109 [33]. 

The interface between the BSF and the BMSC.UPF (see clause 10.4.1) and between the BSF and the SCF (see clause 
10.4.2) is part of the Zn interface to deliver the application security information and defined in 3GPP TS 29.109 [33] 
and 3GPP TS 33.220 [26]. 

4.3 IMS based PSS and MBMS US procedures overview 

Figure 3 describes the IMS based PSS and MBMS procedures from connection establishment to User Service 
Description retrieval. 
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Figure 3: Procedures overview - part 1 

Step 1 to 3: are outside the scope of the present document. 

Step 4: Service discovery, allows the Client to be informed of the available Service Providers. 

Step 5: GBA/GAA bootstrapping procedures, authenticates the User for signalling outside IMS and 

generates the Long Term Key that will be used during content key management procedures. 



Step 6: 
Figure 4 describes the IMS based PSS and MBMS procedures from session establishment to content key management. 



Retrieval of User Service description, allows the client to obtain the service session information 
for the selected provider. 
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Figure 4: Procedures overview - part 2 

Session Establishment, allows the Client to initiate a PSS or MBMS User Service session to 
receive content. 

Policy and Charging Control, are procedures performed via the IMS core to setup relevant bearer 
QoS and charging functions. 

Content Key Management is necessary to generate and distribute the keys to allow secure delivery 
of content to the User. At this stage, the delivery session is established and content is delivered to 
the client. 



4.4 PSS and MBMS user profile and UE capabilities 

4.4.1 User profile description 

The PSS and MBMS user profile data contains all information required to operate PSS and MBMS user services. 

The part of the PSS & MBMS user profile used for On Demand (CoD in TISPAN) and Live (BC in TISPAN) services 
shall be as defined in TISPAN TS 183 063, Annex C. 

4.4.2 UE capabilities 

A set of PSS and MBMS UE capabilities is required to personalize and operate PSS and MBMS user services. These 
capabilities are described in 2 documents: 

• The PSS and MBMS UE Capabilities XML document defined in Annex G. 

• The RDF/XML document for the PSS base vocabulary specified in Annex F of TS 26.234 [8]. 
These 2 documents are sent during the Service Discovery procedure. See clause 6. 

4.4.3 Storage location 

PSS and MBMS user profile and UE capabilities information may be stored in the following locations: 

• Application Server functions. 

• In a stand-alone server associated with one or more Application Server functions. 

• In the HSS as transparent data associated to these Application Server functions. 

The first and second options are recommended for data to be accessed by 3rd party application server functions. In the 
first and second case the Application Server function or the stand-alone server may exhibit the behaviour of an XDMS. 
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User data stored in the HSS can be accessed by Application Servers at the Sh reference point. 

A subset of PSS and MBMS user-profile information may be accessed from the User Equipment at the Ut reference 
point. 

For the purpose of personalized service selection, the SSF may need to access user data. 

In the case when such user data is stored in the HSS, it can be accessed by the SSF at the Sh reference point when the 
SSF is in the same domain. 

On the contrary, when such user data is stored in the AS or in a stand alone server associated with one or more 
application servers or if the SSF in not in the same domain as the HSS, the user data can be accessed by the SSF using 
an interface that is out of scope for this release. 

The SSF may also request notification of user data updates. 



Service Provider Discovery 



5.1 



Introduction 



In order for the UE to access the PSS and MBMS User Service using IMS, it shall implement an IMS client that 
registers to the IM CN Subsystem [7]. This assumes that the UE has attached to a network and established PS 
connectivity through a PDP context according to 3GPP TS 23.060 [16] and has successfully completed the P-CSCF 
discovery procedure [7]. Once the UE is registered to the IM CN Subsystem, it can proceed to the Discovery of the PSS 
and MBMS User Service. 

This clause specifies how the UE performs the PSS and MBMS Service Provider Discovery. This is equivalent to 
discovering the list of IMS PSI of the SDF and relative Service Providers. There are several means for the UE to 
acquire this information. The UE shall implement the DNS based Service Provider Discovery as defined in clause 5.2. 
Other methods are optional. 



5.2 



DNS 



In this case, the SDFs are discovered using the DNS SRV mechanism in accordance with RFC 2782 [17], with the 
following input parameters: 

• Service: Defined as "pss-mbms-user-service". 
NOTE: to be registered with IAN A. 

• Protocol: Can take values "http" or "sip". Specifies the protocol to contain the particular service. 

• Domain name: the domain for which the returned records are valid. The value can be derived from the ISIM. 
Without ISIM it can be derived from USIM together with MCC (Mobile Country Code) and MNC (Mobile 
Network Code) according to TS 23.003 [29]. If not possible, the domain name can be derived from network 
attachment phase (DHCP server). Manual configuration overrides these possibilities. 



UE 



PS core/RAN 



DNS server 



DNS query 



DNS Reply 



Figure 5: Service Provider Discovery withi DNS 
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The output of the DNS SRV lookup is an ordered Ust of domain name, each pointing to a SDF server available within 
the specified Domain name. 

5.3 Others 

Alternatively, the SDF PSI may also be signalled to the UE by the following means: 

• Manually provisioned in the UE. 

• OMA Device Management. 

• SMS. 

• OMA Push. 

• MBMS. 

• DHCP. 



User Service Discovery 



6.1 Introduction 

This clause specifies how the UE performs the PSS and MBMS User Service Discovery. This is equivalent to 
discovering the address of the SSF. 



6.2 Subscribe/Notify 
6.2.1 General description 



UE 



IMCN 
subsytem 



SDF 





SIP SUBSCRIBE 




SIP SUBSCRIBE 






SIP 200 OK 




SIP 200 OK 




SIP NOTIFY 




SIP NOTIFY 




SIP 200 OK 




SIP 200 OK 















Figure 6: Service Discovery with Subscribe/Notify 

1) The UE sends a SIP SUBSCRIBE message to the IM CN subsystem. It should indicate its capabilities in the 
message. 

2) The IM CN subsystem forwards the request to the SDF, e.g. thanks to an iFC. 
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3) The SDF determines the proper service discovery information, e.g. according to the UE capabihties, the user's 
profile (Personalized Service Discovery). The user profile may be retrieved from the HSS or any other entity 
where it is stored. 

4) The SDF sends a SIP 200 OK response to the IM CN subsystem, which forwards it to the UE. 

5) The SDF sends a SIP NOTIFY message to the UE, with service discovery information that includes the SSF(s) 
address(es). 

6) The IM CN subsystem relays the SIP NOTIFY message back to the UE, with the service discovery information 
related to PSS and MB MS user service. 

7) The UE sends back a SIP 200 OK response to the IM CN subsystem. 

8) The IM CN subsystem forwards the SIP 200 OK to the SDF. 

6.2.2 Procedures at the UE 

6.2.2.1 Introduction 

The UE shall generate a SUBSCRIBE request. The behaviour of the UE when processing a SUBSCRIBE request shall 
conform to 3GPP TS 24.229 [7]. 

6.2.2.2 Subscription 

When the UE intends to retrieve service attachment information from the SDF, it shall generate a SUBSCRIBE request 
for the "ua-profile" event package defined in [28] and extended as described in [18]. 

The contents of the SUBSCRIBE request shall be as follows: 

• The value of the Request-URI shall be set to one of following: 

the PSI of the SDF which is retrieved using SDF Discovery procedures in clause 5 Service Provider 
Discovery; or 

the public user identity of the end user (when the UE does not know the PSI of the SDF). 

• The From and To header shall be set to the public user identity of the user. 

• The Accept header shall include the content-type identifier that corresponds to the registered MIME type of 
XML documents representing UE capabilities included in the body. See clause 4.4.2: 

• A first Content Type set to "application/3gpp-ims-pss-mbms-ue-capabilities+xml". 

• A second Content Type set to "application/rdf+xml". 

• The Event header shall be set to the "ua-profile" event package. 

• The Event parameters shall be set as follows: 

The "profile-type" parameter shall be set to "application". 

The "vendor", "model" and "version" parameter values shall be set to values specified by the implementer of 
the user equipment, as specified in 3GPP TS 24.229 [7]. 

The "appids" parameter shall be present and set to "urn:org:3gpp:applications:ims-pss-mbms-service- 
discovery". 

The UE shall include a SIP SUBSCRIBE multipart/mixed content-type message body associated with the appid 
including the PSS and MBMS UE Device Capabilities defined in Annex G and the RDF/XML document describing the 
PSS base vocabulary defined in Annex F of TS 26.234 [8]. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 
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The UE shall automatically refresh the subscription, either 600 seconds before the expiration time if the initial 
subscription was for greater than 1 200 seconds, or when half of the time has expired if the initial subscription was for 
1 200 seconds or less. If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the UE shall 
still consider the original subscription valid for the duration of the most recently known "Expires" value according to 
3GPP TS 24.229 [7]. Otherwise, the UE shall consider the subscription invalid and start a new initial subscription 
according to 3GPP TS 24.229 [7]. 

6.2.2.3 Receiving notifications 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription, the application within the 
UE shall parse the XML document contained in the message body. The XML document schema is defined in Annex H. 
The definition of each parameter in the XML document is defined in 5.2.2.3 of [24] 

The list of parameters in the XML document shall be used for service selection information retrieval according to 
clause 7. 

When parsing the list of parameters the UE shall take the following action: 

• information relates to an SSF with whom the UE has already an entry. 

If the " ©version" attribute is present and has not the same value or if not present, then the UE performs 
the following actions: 

■ for parameters related to this SSF already present in the UE: the UE shall update these parameters 
with the new values sent by the SDF. If the Segment ©Version has not the same value, the UE shall 
update user service selection information from the SSF before using it, 

■ for parameters related to this SSF not present in the UE: the UE shall store the new parameters. 

If the "©version" attribute is present and has the same value, the UE shall not update the stored SSF 
information. 

• information relates to an SSF not known by the UE: the UE creates a new entry for this SSF with all indicated 
parameters. 

After all elements have been processed, the UE shall return a 200 OK response to the NOTIFY request. 

Failure to perform subscription refresh does not imply that there is a loss of communication to SSF or SCF. The UE has 
an option to continue using the lists of parameters from the last NOTIFY. 

After deregistration, the UE may keep stored information on per user basis. As for subscription refresh, the UE may use 
the stored information if initial subscription fails after a new registration. 

6.2.3 Procedures at the SDF 

The SDF addresses are determined by the UE using any of the alternatives as defined in clause 5. 

When the SDF receives a SUBSCRIBE request, it may perform user's identity verification as defined in 
3GPP TS 24.229 [7]. After successful user identification, if a User Profile is available it is possible to perform 
personalization of the body (Service Attachment Information) of the NOTIFY request. 

The SDF shall examine the parameters specified in the SIP SUBSCRIBE body and shall then record UE capabilities 
information as part of the user profile data. 

NOTE: The UE capabilities that are recorded as part of the user profile may be used by the SSF for 
personalization purposes. 

In case of successful subscription, the SDF shall generate a SIP 200 OK in response to the SUBSCRIBE request. The 
SDF shall then send a NOTIFY request immediately. 

The contents of the NOTIFY request shall be as follows: 

• The Event header shall be set to the "ua-profile" event package. 

• The "effective-by" parameter for the event header shall be set to 0. 
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• The content type shall be set to "application/3gpp-ims-pss-mbms-service-discovery+xml"; 

• The message body shall contain an XML document listing SSF addresses and the means of connecting to the 
SSFs for retrieving service selection information defined in Annex H. The definition of each parameter in the 
XML document is defined in 5.2.2.3 of [24]. The "©technology" element name indicates the technology used to 
for delivering service selection information. It shall be set to the "openmobilealliance.org_bcast". 

When any parameter of service configuration information has changed, the SDF may generate a NOTIFY request 
including new service configuration information. 



7 User Service Description retrieval 

7.1 Introduction 

User Service Description retrieval can be done in several ways 

By retrieving OMA BCAST Service Guide information [27] from the SSF. See clause 7.2; 

By retrieving MBMS USD from the SSF as defined in 3GPP TS 26.346 [11] clause 5.2; 

By executing the Procedure for providing missing parameters before session initiation described in 
clauses 8.2.2 and 8.3.2 for PSS and MBMS user service respectively. 

7.2 User Service Description retrieval for PSS and MBMS 
7.2.1 Procedures at the UE 

7.2.1 .1 Procedure for Service Personalisation 

For HTTP-based data retrieval, when sending the HTTP request to the SSFs, the UE may provide personalized 
information to enable a personalized answer. This shall be done by adding the X-3GPP-Intended-Identity HTTP header 
to the request to transmit the public identity. 

The authentication shall follow 3GPP TS 33.222 [20]. 

The UE shall implement Transport Layer Security (TLS), as described in 3GPP TS 33.222 [20]. 

7.2.1 .2 Request of OMA BCAST ESQ 

In the pull model of unicast delivery of an OMA BCAST ESG, the HTTP protocol shall be used conforming to OMA 
BCAST Service_Guide [27], clause 5.4.3. 

7.2.1 .3 Use of Service Description information 

The UE shall use parameters received from the SSF for session initiation. 

NOTE: There is no restriction on the UE to use any parameter received from SSF also for other purposes than 
session initiation, e.g. to present SSF information to the user. 

The UE may store a part of the ESG information covering certain period of time and refresh this information 
periodically This avoid the UE to contact the SSF every time the user needs to consult the ESG. 

If the UE is unable to contact any discovered SSF, it shall not delete stored information immediately. 
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7.2.2 Procedures at the SSF 

7.2.2.1 Authentication and authorisation in case of personalized service description 
information 

In case of service selection personalisation the SSF shall authenticate the user. 

The authentication shall follow 3GPP TS 33.222 [20]. 

The SSF shall implement Transport Layer Security (TLS) as described in 3GPP TS 33.222 [20]. 

An authentication proxy (AP) may exist between the UE and the SSF in which case the behaviour of the AP is assumed 
to conform to 3GPP TS 24.423 [21]. 

If an Authentication Proxy (AP) is provided in the path of the HTTP request, then the SSF receives an HTTP request 
from a trusted source (the AP) and the request contains an HTTP X-3GPP-Asserted-Identity header 
(3GPP TS 24.109 [22]) that includes an asserted identity of the user. In this case the SSF does not need to authenticate 
the user, but just provide authorization to access the requested resource. 

If an HTTP X-3GPP-Asserted-Identity header (3GPP TS 24. 109 [22]) is not present in the HTTP request or if the 
request is received from a non-trusted source, then the SSF needs to authenticate the user prior to providing personalise 
information by applying the procedures defined in 3GPP TS 33.222 [20] and 

authorize or deny authorization depending on the authenticated identity. 

7.2.2.2 Procedure for Service Personalization 

If the public user identity information is present in the query from the UE, the SSF shall extract it to 
customize/personalize the service information that is returned in the query response. 

The SSF shall use the public user identity that is specified in the X-3GPP -Intended-Identity header or the 
X-3GPPAsserted-Identity header if an authentication proxy is used to fetch the corresponding user profile associated 
with the user. For instance, the Parental Control (if present) should be used to remove unsuitable elements from the 
COD listings that are returned to the UE. 

7.2.2.3 Delivery of OMA BCAST ESG 

The procedure for retrieving OMA BCAST service selection information is employed to retrieve one or more Service 
Guide Delivery Descriptors (SGDD) and/or Service Guide Delivery Units (SGDU). The SGDD describes service level 
information as well as access information to the Service Guide fragments. The SGDU is the transport-independent 
network structure for encapsulating Service Guide fragments. 

When the ESG SSF receives a HTTP POST request, if personalization headers are presents (in the form of key-value 
pairs) it shall use those headers in order to build a personalized response. For instance, the ESG SSF may use the 
provided user identity to retrieve the associated Parental Control Level in the user profile. This Parental Control Level 
would then be used to remove non suitable elements from the ESG data that are sent back. The provided user identity 
may also be used to retrieve a personalized ESG using the method in OMA BCAST Service Guide [27], 
clause 5. 4. 3. 3. The ESG SSF shall send an HTTP response conforming to OMA BCAST Service Guide [27], clause 
5.4.3.1. The body of the HTTP response shall contain an XML document with SGResponse data, conforming to OMA 
BCAST Service Guide [27], clause 5.4.3.1.1. 



8 Streaming session and media control 

8.1 General 

This clause specifies the procedures and protocols used for the IMS based initiation and control of streaming sessions 
on PSS or MBMS User Service. 
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The client shall use SIP to initiate and control PSS and MBMS streaming sessions. Once a PSS streaming session is 
established, the client shall use RTSP protocols to perform media control. 

8.2 PSS Streaming 

8.2.1 PSS Media codecs and formats 

PSS Media codecs and formats defined in 3GPP TS 26.234 [8] are applicable to the present document for IMS initiated 
and controlled PSS services. 

8.2.2 Procedure for providing missing parameters before session initiation 

8.2.2.1 Procedures at the UE 

If the UE does not have all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS message: 

• The "Request-URI" is related to the PSS session that the user wants to activate. The Request-URI shall be 
composed of a user and domain part as defined as follows: 

The user part contains the content identifier, retrieved from user service description information from SSF. 

o For COD service, content identifier is constructed by 'PSS_COD_<content-id>', wherein content-id 
shall be globalContentID defined in [27]. 

o For Live service, content identifier shall be globalServicelD defined in [27] or serviceld defined in 

[11]. 

The domain part is the Service Provider domain name, obtained from SSF. 

• The TO header shall contain the same URI as in the "Request-URI" parameter. 
The other headers shall be set according to TS 24.229 [7]. 

Upon reception of the 200 OK including SDP, the UE shall initiate PSS session as described in clause 8.2.3. 

8.2.2.2 Procedures at the SCF 

When receiving the SIP OPTIONS message, the SCF shall select the appropriate PSS Adapter and forward the SIP 
request to the appropriate PSS Adapter by changing the "Request-URI" accordingly. 

The SCF shall not change the user -part of the TO header in order to keep the content-id in the OPTIONS request. 

8.2.2.3 Procedures at the PSS Adapter 

When receiving SIP OPTIONS request, the PSS Adapter shall examine the content identifier present in the user-part of 
the TO header. 

If the PSS adapter does not have the user service description information, it shall send an RTSP DESCRIBE message to 
the PSS server to retrieve the user service description information 

Then, the PSS Adapter shall answer with the user service description information of the content delivery channel in 
SDP as requested by the request URI. 
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8.2.3 PSS Streaming Session initiation 
8.2.3.1 General description 
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SIP INVITE (Request-URI, SDP) 



SIP 200 OK (SDP, Session ID, URI) 
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RTSP DESCRIBE 

RTSP SDP 
RTSP SETUP(s) 
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Figure 7: IMS based PSS initiation 

NOTE 1: This sequence is simplified and does not e.g. show session progress messages and the ACK message from 
the UE in response to the reception of 200 OK. 

NOTE 2: SIP messages between PSS adapter and SCF go through the IM CN Subsystem even if not indicated on 
the sequences. 

8.2.3.2 Procedures at the UE 

The UE shall generate an initial INVITE request according to TS 24.229 [7] with the following additions: 

• The Request-URI is related to the PSS session that the user wants to activate. 

• For an On Demand service, it shall be composed of a user part and a domain part, as follows: 

• A user part containing the content identifier in a free string format. 

• Content identifier is constructed by 'PSS_COD_<content-id>', wherein content-id shall be 
globalContentID defined in [27]. 

• A domain part containing the content provider domain name, obtained from the SSF. 

• For Live content, it shall contain the PSI (Public Service Identity) of the "Live stream@<domain name>", 
wherein the domain name is obtained from SSF". 

• The To header shall contain the same URI as in the Request-URI. 

• The Recv-Info header shall be set to nil [42] . 

The other headers shall be set according to TS 24.229 [7]. 

An SDP Offer shall be included in the initial INVITE request, in accordance with media capabilities and policies 
available for the PSS session and with the parameters received from the SSF during service selection procedure. 
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The SDP offer shall contain a media description for the RTSP content control channel and one for the content delivery 
channel. The RTSP content control media description shall be carried by TCP. 

The SDP parameters for the RTSP content control channel shall be set as follows: 

• a 'm' line for an RTSP stream of format: m=<media> <port> <transport> <fmt> 

The media field shall have a value of "application". 

- The port field shall be set to a value of 9, which is the discard port. See RFC 4145 [13] and RFC 4572 [14]. 

The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top of 
TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. 

The <fmt> parameter shall be included and shall be set to 3gpp_rtsp. 

NOTE: the 3gpp_rtsp application format should have a new MIME subtype registered in IAN A. 

An "a=setup" attribute shall be present and set to "active" indicating that the UE will initiate an outgoing 
TCP connection to the PSS Adapter [7] and [13]. 

An "a= connection" attribute shall be present and set as "new" " indicating that the UE will establish a new 
outgoing TCP connection towards the PSS Adapter [7] and [13]. 

A "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP 
address of the flow of the related RTSP content control (ex. c=IN IP4 <IP_ADDRESS>). 

For Live service, an 'a=PSS_Live_service: ServicelD' line shall be include to indicate the PSS live service 
which the UE intends to initiate. The ServicelD shall be globalServicelD defined in [27] or serviceld defined 
in [11], which is retrieved from service selection information. 

Example of RTSP "m' line offer from the UE: 

m=application 9 TCP 3gpp_rtsp 
C=IN IP4 192 .0.2.2 
a=setup : active 
a=connection : new 

For each media stream controlled by the RTSP content control channel, the SDP offer shall include a "receiver only" 
content delivery channel media description set as defined in 3GPP TS 26.234 [8], clause 5.3.3: 

• the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery 
channel. It may also include a fmt parameter which shall indicate the format given by the SSF or by executing 
the procedure for providing missing parameters before session initiation described in clauses 8.2.2, a subset of 
them or the format offered by the UE if none is given by the SSF; 

• the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and 
unicast address of the flow of the related content delivery channel; 

(ex. c=IN IP4 <IP_ADDRESS>) 

• optionally a "b=" line may contain the proposed bandwidth. If the user has fetched the bandwidth required for 
this particular content delivery channel during service selection retrieval, the bandwidth attribute at media level 
shall be set to this value. Otherwise, this attribute shall be set to a pre-configured value; 

(ex. b=AS: 15000) 

• A "a=" line with a "recvonly". 

The UE should receive a SIP 200 OK back containing the answer SDP. 

8.2.3.3 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 
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8.2.3.4 Procedures at the SCF 

Upon receipt of SIP INVITE request, the SCF shall examine the Request-URI and SDP parameters to determine that it 
is a PSS session initiation request for Live Streaming or Content-On-Demand. According to the user subscription 
information, the SCF shall check the service rights of the requested PSS service. 

If the Request-URI contains a content identifier in the user part and a domain name in the domain part, the SCF 
determines that the PSS streaming session is initiated for On Demand content. In this case, the SCF shall select a 
suitable PSS adapter and forwards the SIP INVITE to the selected PSS adapter by changing the Request-URI 
accordingly. The SCF shall not change the user part of the To header in order to keep the content identifier in the 
INVITE request. 

When receiving a 301 or 302 response from the PSS adapter, the SCF shall not forward this message to the UE. It may 
check if the PSS adapter indicated in the Contact header belong to allowed destination. If allowed, the SCF shall use 
one of the PSS adapter URI indicated in the Contact header of this response and use it as a destination for the redirected 
INVITE. 

If the request-URI contains the PSI " Live Stream", the SCF determines that the PSS streaming session is initiated for 
Live content. In this case, the SCF shall select a suitable PSS adapter and forwards the SIP INVITE to the selected PSS 
adapter. The SCF shall include the list of authorized Live content channels for the user in the SIP INVITE transmitted 
to the PSS adapter by including the package identifiers containing to the list of authorized Live content channels for the 
session and optionally transmitting the list of authorized RTSP URIs. 

The Recv-Info header shall indicate the supported Info Package (Content reporting) for reception and processing by the 
SCF [42]. 



Based on the Request-URI and SDP parameters, the SCF selects a suitable PSS Adapter and forwards the SIP INVITE 
to the selected PSS Adapter. 

Once receiving a SIP 200 OK response from PSS Adapter, the SCF shall forward the response to UE. 

8.2.3.5 Procedures at the PSS Adapter 

The PSS Adapter shall be statefully aware of any sessions between the PSS Adapter and a UE, and the PSS Adapter and 
the PSS Server related to the same streaming session . This means that the RTSP session between the PSS Adapter and 
the PSS Server and the SIP & RTSP sessions between the PSS Adapter and the UE are associated at the PSS Adapter in 
order to keep session structure and alignment. This includes, but is not limited to, RTSP parameters such as sessionid, 
IP version, CSeq, etc. 

The PSS Adapter shall support the following RTSP methods for PSS Server session establishment and teardown 
control: 

• DESCRIBE (PSS Adapter to PSS Server). 

• SETUP (PSS Adapter to PSS Server). 

• TEARDOWN (PSS Adapter to PSS Server). 

The PSS Adapter should support the "3gpp-pipelined" feature so as to be able to pipeline SETUP messages. 
Upon receipt of a SIP INVITE message, the PSS Adapter performs the following actions: 

• It shall resolve the RTSP URI based on the R-URI, the SDP parameters and the selected PSS Server. 

• It may send a DESCRIBE message to the PSS Server to fetch the SDP file. 

• It shall construct and send the RTSP SETUP message(s) to setup the relevant media streams. 

• Return the answer SDP to the UE in the SIP 200 OK. 

The PSS Adapter shall construct the RTSP SETUP message according to the SIP Invite as follows: 

• The Request-Line shall be present of format: Request-Line = Method SP Request-URI SP RTSP- Version CRLF: 
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— Method field is set to SETUP; 

— RTSP- Version field to be set of RTSP/1 .0. 

• The CSeq header field is set to a value allocated by PSS Adapter according to RFC 2326 [25] 

• The transport header field: 

— the protocol and profile sub -fields together are set to a value of the protocol sub-field of the corresponding 
"m=" Une in the SDP offer, 

— the unicast I multicast parameter is set to unicast. 

— The destination parameter is set to a value of the "c=" line of the corresponding media delivery channel in 
the SDP offer, 

— The RTP port value of client_port parameter is set to the value of the port sub-field of the corresponding 
"m=" line in the SDP offer, and the RTCP port value of client_port parameter is set to a value of the RTP port 
value plus 1 . 

An example of the RTSP SETUP message is: 

PSS Adapter->PSS Server: SETUP rtsp://media.example.com/movie001/audiotrack RTSP/1 .0 
CSeq: 1 

Transport: RTP/AVP/UDP; unicast; destination=<IP ADDRESS>; client j}ort=3400-3401 
The PSS Adapter may send multiple RTSP SETUP messages if multiple media delivery channels are carried within the 
SDP offer. In this case, the pipeline of multiple RTSP SETUP messages may be supported. 

When receiving a RTSP 200 OK response from the PSS Server, the PSS Adapter parses the response, constructs a SIP 
200 OK response with the final SDP, and sends the SIP 200 OK response to the SCF. The final SDP shall describe the 
RTSP session established by the PSS Adapter and the TCP connection to be established by the UE. 

The PSS Adapter shall construct the SIP 200 OK message according to RTSP 200 OK as follows: 

• The Recv-Info header shall be set to nil [42]. 

• an 'm' line for an RTSP stream of format: m=<media> <port> <transport> <fmt> 

— The media field shall have a value of "application". 

— The port field shall be set to the value allocated by PSS Adapter for the UE to establish RTSP session, such 
as 554. 

— The transport field shall be set to TCP or TCP/TLS. The former is used when RTSP runs directly on top of 
TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. 

• a "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP address 
of PSS Adapter for the flow of the related RTSP content control (e.g. c = IN IP4 <IP_ADDRESS>). 

• The "setup" attribute is set to 'passive' indicating that connection shall be initiated by the other endpoint (UE). 

• An "a= connection" attribute shall be present and set as "new" indicating that the UE will establish a new outgoing 
TCP connection towards the PSS Adapter [7][13]. 

• An "a=control" attribute shall be present in the format of an absolute URI to be used for the UE in the subsequent 
RTSP requests. 

• One or more a=fmtp lines representing RTSP specific attributes set as follows: 

a "fmtp:3gpp_rtsp h-session" attribute representing the session identifier for the RTSP session to be 
established with the UE. 
The PSS Adapter may include "fmtp: 3gpp_rtsp h-offset" attribute that indicates where the playback is to start from. 

Example of RTSP "m' line answer from the PSS Adapter: 

m=application 554 TCP 3gpp_rtsp 

c=IN IP4 192.0.2.1 

a=setup ipassive 

a=connection : new 

a=control : rtsp : //example . com/channel/contentl . sdp 

a=fmtp 3gpp_rtsp h-session=12345 

a=fmtp 3gpp_rtsp h-offset=30 

For each media stream controlled by the RTSP content control channel, the SDP answer shall include a content delivery 
channel media description set as follows: 
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• the "m=" line indicates the type of the media, the transport protocol and the port of the related content delivery 
channel. 

• The port value shall be set to the RTP port value retrieved from the server_port parameter in the RTSP 200 OK 

message. 

• If an fmt parameter is in the SDP offer it shall be completed with the supported format by the PSS Server; 

• the "c=" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and the 
unicast address of the PSS Server for the flow related to the content delivery channel, 

(ex. c=IN IP4 <IP_ADDRESS>); 

• the "b=" line shall contain the proposed bandwidth. Since the PSS media stream is unidirectional the bandwidth 
shall be set to 0, except for the case that the transport is RTP and RTCP is allowed. 

(ex. b=AS:0); 

• an "a=" line with a value of "sendonly". (ex. a=sendonly). 



8.2.4 PSS Streaming Playback Control 
8.2.4.1 General Description 
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Figure 8: Initial Payback 

8.2.4.2 Procedures at the UE 

The UE shall support the following RTSP methods for RTSP playback control: 

• PLAY (UE to PSS Adapter). 

• PAUSE (UE to PSS Adapter). 

• GET_PARAMETER (UE to PSS Adapter). 

• SET_PARAMETER (UE to PSS Adapter). 

• OPTIONS (UE to PSS Adapter). 

When receiving any SIP response, the UE shall examine the media parameters in the received SDP: the UE shall 
immediately setup the TCP connection carrying RTSP. The UE shall fetch the RTSP session ID from the SDP answer 
contained in the SIP response. This RTSP session ID shall be used for RTSP media control messages. 

After SIP session establishment, the UE can exchange RTSP messages to start to receive media streams. The UE shall 
send an RTSP PLAY message to the PSS adapter according to 3GPP TS 26.234 [8]. 
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• The RTSP URL shall be set to the value retrieved from the SDP "a=control" attribute in the case of an absolute 
URL If the value of "a=control" is a relative URI that is in the form of a media path, then the RTSP absolute 
URL is constructed by the UE using the SDP IP address (from c-line) and port (from m-line) as the base 
followed by "a=control" value for the media path. 

• The RTSP session ID in the h-session received in the SDP shall be used in RTSP media control messages. 

• The version attribute shall be present in the SDP and its value shall be LO in this version of the specification. 

• If the h-offset attribute is present in the SDP, the Range parameter in the first RTSP PLAY message may be set 
to its value. E.g. Range: npt=<OFFSET>- (with OFFSET being the value of the h-offset attribute). 

8.2.4.3 Procedures at the PSS Adapter 

If the PSS Adapter supports the proxying of RTSP towards the PSS Server then the following methods shall be 
supported: 

• PLAY; 

• PAUSE; 

• GET_PARAMETER; 

• SET_PARAMETER; 

• OPTIONS. 

Upon receipt of a RTSP message from an UE, the PSS Adapter shall match the RTSP session with the RTSP sessions 
once established with PSS Server according to the Session ID carried in the received RTSP message. If there is a 
session match, PSS Adapter shall send the RTSP message to PSS Server on the matched RTSP session. If no session 
matches, PSS Adapter shall response with a RTSP error code 454 (Session Not Found). 

When receiving a RTSP response message from a PSS Server, the PSS Adapter shall match the RTSP session with the 
RTSP sessions once established with UEs according to the Session ID carried in the received RTSP response message, 
and send the RTSP response message to UE on the matched RTSP session. 

The PSS Adapter should send a SIP INFO message to the SCF indicating that playback has started. This SIP INFO 
message should be equal to the SIP INFO messages for PSS content switching defined in clause 8.2.5. 

8.2.4.4 Procedures at the PSS Server 

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8]. 

8.2.5 PSS content switching 

8.2.5.1 PSS Streaming session modification 

8.2.5.1.1 General description 

NOTE 1 : The specification assumes the UE will trigger a Re-INVITE procedure to change the QoS to fit the new 
channel requirements. It will be considered whether the network can trigger the QoS change without the 
UE taking management. 

This procedure presents the generic PSS streaming session modification procedure. It can be referred in some cases for 
PSS Content Switching, when there is a change of media components and/or bandwidth. 
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Figure 9: UE-initiated PSS session modification 

NOTE 2: Like in other call-flows of the specification, the figure does not show that messages exchanged between 
the PSS adapter and the SCF are routed through the IM CN subsystem. 

1) The UE sends the Re-INVITE request containing the SDP offer to the IM CN Subsystem to establish the 
content delivery channel. The IM CN Subsystem may require the PCRF to reserve additional resources for 
RTP streams according to the SDP in the Re-INVITE. The IM CN subsystem may also issue the PCRF to 
release resources for RTP streams. 

2) The IM CN Subsystem forwards the Re-INVITE request to the SCF. 

3) The SCF sends the Re-INVITE to the PSS adapter via the IM CN Subsystem. 

4) The PSS adapter sends the according number of RTSP SETUP to the PSS server, if additional media 
components are described in the SDP. 

5) The PSS server responds with RTSP 200 OK to the PSS adapter (only, if the PSS adapter has send SETUP 
messages to the PSS Server). 

6) The PSS adapter sends one SIP 200 OK to the SCF with the SDP answer containing the new media 
descriptions of RTP streams to be used. 

7) The SCF sends the SIP 200 OK to the IM CN Subsystem. The IM CN subsystem interacts with the PCRF to 
commit the reservation, and then forwards the SIP 200 OK to the UE. 

8) The UE sends the SIP ACK to the IM CN subsystem, which forwards to the SCF. The SCF forwards the SIP 
ACK to the PSS adapter. 



8.2.5.1.2 



Procedures at the UE 



To modify the session, the UE shall send a Re-INVITE or an UPDATE request as specified in TS 24.229 [7] for an 
originating UE. 

The UE shall not modify RTSP channel m-line description in the SDP if the media delivery streams controlled by RTSP 
are not removed (port not set to in the m lines) in the SDP. 
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8.2.5.1 .3 Procedures at the IM CN subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.1.4 Procedures at the SCF 

Upon receipt of a Re-INVITE request or an UPDATE request, the SCF shall follow the procedures defined in TS 
24.229 [7] concerning the AS acting as a proxy or a B2BUA. 

When receiving an SDP offer, the SCF may modify the SDP offer in accordance to the user subscription. If the SCF 
finds a media line not compatible with the user's subscription, it shall set the port of this media line to 0. If none of the 
media lines are acceptable, it shall reply with a 403 error response. 

Then the SCF forwards the Re-INVITE message to the PSS adapter. 

8.2.5.1 .5 Procedures at the PSS adapter 

Upon receipt of a Re-INVITE request or an UPDATE request, the PSS adapter shall modify the session as specified in 
TS 24.229 [7] if the request is acceptable to the PSS adapter in accordance with the user subscription. 

The PSS adapter sets up new media components, if the SDP file contains additional components. 

8.2.5.1 .6 Procedures at the PSS server 

Upon receipt of an RTSP setup, the PSS server executes the requested method and responds with an RTSP status code 
to the PSS adapter. 

8.2.5.2 PSS Content switching with available SDP, no change of media component 

and bandwidth 

8.2.5.2.1 General description 

The UE has retrieved the SDP prior to the content switching. The procedure is as described as in 3GPP TS 26.234 [8], 
with the server role being played by the PSS adapter. 
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Figure 10: IMS PSS Content switching 

1) The UE sends a PLAY request with the aggregated control URI of the new content to the PSS adapter. The 
PSS cHent adds the media control URIs of the new streams in the "Switch-Stream" header field to the RTSP 
PLAY method request as defined 3GPP TS 26.234 [8] clause 5.5.4.3. 

2) The PSS Adapter sends the RTSP PLAY message to the PSS Server. 

3) The PSS Server responses a RTSP 200 OK message to the PSS Adapter. 

4) The PSS Adapter sends the RTSP 200 OK message to UE. 

5) The PSS server delivers the switched content streams to the UE. 

6) The PSS Adapter should send a SIP INFO message including the Info Package (Content Reporting) to the SCF 
with content switching information. See clause 8.2.5.2.5. 

The SCF may utilize the content switching information for statistic, charging etc. purpose, and may initiate a SIP Re- 
INVITE request to the UE to adjust the QoS reservation if the transport resources changed before and after switching. 



8.2.5.2.2 



Procedures at the UE 



To switch content of the PSS streaming session the UE shall send an RTSP PLAY request with the new content URI as 
defined in TS 26.234 [8] clause 5.5.4. 

8.2.5.2.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.2.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 
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8.2.5.2.5 Procedures at the PSS Adapter 

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message with the Info Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an 
XML document as defined in Annex D and Annex E. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 

8.2.5.2.6 Procedures at the PSS Server 

The PSS Server reacts as defined in 3GPP TS 26.234 [8] clause 5.5.4. 

8.2.5.3 PSS Content switching with available SDR, change of media components or 

QoS 

8.2.5.3.1 General Description 

Fast Content Switching as defined in 26.234 [8] Clause 5.5.4 allows also changing content when the new content 
channel requires a different number or characteristics of media components as the old content channel, or when the 
bandwidth needs to be modified. 

For instance, the old content stream consists out of an audio and a video stream and the new content channel offers an 
audio, video and 3GPP Timed Text media component. Addition a media component to an ongoing stream is defined in 
26.234 [8] clause 5.5.4.6 and removing a media component in 26.234 [8] clause 5.5.4.7. 
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Figure 1 1 : IMS PSS Content switching 

NOTE 1: This sequence is simplified and does not e.g. show the ACK message from in response to the reception of 
200 OK. 

NOTE 2: The number of required RTSP SETUP interactions between the PSS Adapter and the PSS Server depend 
on the number of new media components in the SDP. 

The UE determines that the new SDP file contains a different number of media components as the old SDP. The UE 
updates the streaming session by sending a Re-INVITE with the new SDP file, as described in clause 8.2.3.2. The Re- 
INVITE is sent either before, during or after the RTSP PLAY switch. As soon as the UE receives the 200 OK for the 
Re-INVITE, the UE initiates a PLAY to get the new synchronization information. 



8.2.5.3.2 



Procedures at the UE 



The UE shall send an RTSP PLAY request with the new content URI as defined in TS 26.234 [8] clause 5.5.4. The UE 
changes the number of media components by sending a Re-INVITE message with the new SDP offer. After receiving 
the 200 OK for the Re-INVITE the UE initiates a PLAY to get the new synchronization information. 
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8.2.5.3.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.3.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 

8.2.5.3.5 Procedures at the PSS Adapter 

Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message with the Info Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an 
XML document as defined in Annex D and Annex E. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 

When receiving the SIP Re-INVITE message from the SCF, if a new media component needs to be added or removed, 
the PSS adapter shall send the RTSP SETUP to the PSS server, indicating the new media component that needs to be 
added or removed. 

8.2.5.3.6 Procedures at the PSS Server 

The PSS Server behaves as defined in 3GPP TS 26.234 [8] clause 5.5.4 

8.2.5.4 PSS Content switching with unavailable SDR, no change of media 

component and/or bandwidth 

8.2.5.4.1 General description 

In this case, the UE does not have the SDP for the streams it intends to switch to. The new content has same media and 
bandwidth characteristics. 
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Figure 12: IMS PSS Content switching without available SDP, no change of media component and/or 

bandwidth 

The UE sends a PLAY request to the PSS adapter indicating that it needs the SDP for the new streams. The PSS 
Adapter sends the RTSP PLAY message to the PSS Server. 

The PSS Server responses a RTSP 200 OK message to the PSS Adapter, PSS Adapter sends the RTSP 200 OK message 
to UE containing the SDP for the new streams. 

The PSS server starts streaming the switched content streams to the UE. 

The PSS Adapter should send a SIP INFO message including the Info Package (Content Reporting) to the SCF 
according to clause 8.2.5.2.1. 



8.2.5.4.2 



Procedures at the UE 



To switch content of the PSS streaming session the UE shall send an RTSP PLAY to request the new SDP as defined in 
TS 26.234 [8]. 

8.2.5.4.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.4.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 



8.2.5.4.5 



Procedures at the PSS Adapter 



Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
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message with the Info Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an 
XML document as defined in Annex D and Annex E. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 
The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 
The PSS Adapter sends the RTSP 200 OK message to UE containing the SDP for the new stream. 

8.2.5.4.6 Procedures at the PSS Server 

The PSS Server behaves as defined in 3GPP TS 26.234 [8] clause 5.5.4. 

8.2.5.5 PSS Content switching with unavailable SDP, change of media component 

and/or bandwidth 

8.2.5.5.1 General description 

In this case, the UE does not have the SDP for the streams it intends to switch to. And the new content has different 
media and/or bandwidth characteristics. 
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Figure 13: IMS PSS Content switching without available SDP, 
change of media component and/or bandwidth 

The UE sends a PLAY request to the PSS adapter indicating that it needs the SDP for the new streams. The PSS 
Adapter sends the RTSP PLAY message to the PSS Server.. If the UE receives a "206 Partial Data" success status code, 
then the UE changes the number of media components and/or bandwidth by sending a RE-INVITE message with the 
new SDP file, as described in clause 8.2.5.1. 



8.2.5.5.2 



Procedures at the UE 



If the UE receives a "206 Partial Data" success status code, then the UE changes the number of media components by 
sending a re-INVITE message with the new SDP file. 

8.2.5.5.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.5.5.4 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the PSS adapter. 
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8.2.5.5.5 



Procedures at the PSS Adapter 



Upon identification of a successful content switch, the PSS Adapter starts the content switching timer for a particular 
session. If another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated 
during the life of the timer, the timer is stopped. After timer expiration, the PSS Adapter should send a SIP INFO 
message with the Info Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an 
XML document as defined in Annex D and Annex E. 

ImsPssMbmsCommand shall be set to "PssS witch". 

ContentID is set to the RTSP URI of the new content. 

DateTime is set to the current date and time. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command+xml". 

When receiving the SIP RE-INVITE message from the SCF, if a new media component needs to be added, the PSS 
adapter shall send the RTSP SET-UP to the PSS server, indicating the new media component that needs to be added. 

8.2.5.5.6 Procedures at the PSS Server 

The PSS Server reacts as defined in 3GPP TS 26.234 [8] clause 5.5.4. 



8.2.5.6 



PSS content switching reporting update 



8.2.5.6.1 



General Description 



If the SCF does not want to receive content switching information anymore or would like to start content switching 
reporting, the SCF should send a SIP UPDATE message to the PSS adapter with the Recv-Info header set appropriately. 

Note: In this case, the SCF is acting as B2BUA. 



SCF 




PSS Adapter 




SIP 


UPDA 


1 
1 

rE 1 


1 SIP 200 OK 1 


1* 

1 






1 
1 



8.2.5.6.2 



Figure 13a: PSS content switching reporting update 



Procedures at the PSS adapter 



After receiving a SIP UPDATE message from the SCF, the PSS adapter shall dependent on the Recv-Info header, stop 
or start the content switching reporting. 



8.2.5.6.3 



Procedures at the SCF 



If the SCF does not want to receive content switching information anymore, it should send a SIP UPDATE message 
with the Recv-Info header set to nil to the PSS adapter. 

If the SCF decides to start content switching reports, the SCF should send a SIP UPDATE message with the Recv-Info 
header set to content info to the PSS adapter. 
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8.2.6 PSS Streaming Session Teardown 



8.2.6.0 



Introduction 



Assuming the streaming session is established, the session can be terminated either by the UE or by the network. For 
the network-initiated PSS streaming session teardown, either the SCF or the PSS adapter can initiate the procedure. 

8.2.6.1 General Description 

8.2.6.1 .1 UE-initiated PSS streaming session teardown 
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Figure 14a: UE-initiated IIUIS PSS Session termination 

Here the case of UE termination is described. The following steps are carried out: 

1) Note that the PSS Adapter should maintain the RTSP session to the PSS Server until after step 5. 

2) The UE sends a SIP BYE message. 

3) The IMS CN subsystem forwards the SIP BYE message to the SCF. 

4) The SCF sends the SIP BYE message to the PSS adapter. 

5) The PSS adapter sends a RTSP TEARDOWN to the PSS server. 

6) In case the PSS Server is transmitting RTP data it stops sending RTP data for this session. The PSS server 
sends a RTSP 200 OK to the PSS adapter. 

7) The PSS adapter sends a SIP 200 OK to the UE via SCF and IMS CN subsystem. 
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8.2.6.1.2 
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Figure 14b: SCF-initiated IIVIS PSS Session termination 

Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out: 

1) The SCF sends a SIP BYE to the PSS adapter. 

2) The PSS adapter sends the RTSP TEARDOWN message to the PSS server. 

3) The PSS server sends the RTSP 200 OK message to the PSS adapter. 

4) The PSS adapter sends the SIP 200 OK message to the SCF. 

5) Upon receipt of the SIP 200 OK, the SCF sends the SIP BYE message to the IM CN subsystem. 

6) The IM CN Subsystem forwards the SIP BYE message to the UE. 

7) The UE sends a SIP 200 OK message to the IM CN Subsystem. 

8) The IM CN Subsystem forwards the SIP 200 OK to the SCF. 



8.2.6.1.3 



PSS adapter-initiated PSS streaming session teardown 
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Figure 14c: PSS adapter-initiated IIVIS PSS Session termination 

Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out: 

1) The PSS adapter sends the RTSP TEARDOWN to the PSS server. 

2) The PSS server sends the RTSP 200 OK to the PSS adapter. 
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3) The PSS adapter sends the SIP BYE message to the SCF. 

4) The SCF sends the SIP 200 OK message to the PSS adapter. 

5) The SCF sends the SIP BYE message to the IM CN Subsystem. 

6) The IM CN Subsystem forwards the SIP BYE message to the UE. 

7) The UE sends a SIP 200 OK message to the IM CN Subsystem. 

8) The IM CN Subsystem forwards the SIP 200 OK to the SCF. 

8.2.6.2 Procedures at the UE 

8.2.6.2.1 UE-initiated PSS streaming session teardown 

To teardown the PSS streaming session the UE shall close the TCP connection for RTSP between UE and PSS Adapter, 
if existing. Further, the UE shall send a SIP BYE to the SCF. 

8.2.6.2.2 Networl<-initiated PSS streaming session teardown 

Upon receipt of the SIP BYE message, the UE shall the SIP 200 OK message to the SCF. The UE procedes to release 
the associated resources held for the PSS session. 

8.2.6.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.2.6.4 Procedures at the SCF 

8.2.6.4.1 UE-initiated PSS streaming session teardown 

Upon receipt of a SIP BYE message the SCF shall forward it to the PSS adapter. 

8.2.6.4.2 SCF-initiated PSS streaming session teardown 

The SCF initiates the PSS streaming session teardown by sending a SIP BYE message to the PSS adapter. Upon receipt 
of the SIP 200 OK from the PSS adapter, the SCF shall send a SIP BYE message to the UE. 

8.2.6.4.3 PSS adapter-initiated PSS streaming session teardown 

Upon receipt of the SIP BYE message received from the PSS adapter, the SCF sends the SIP 200 OK message to the 
PSS adapter. Then the SCF forwards the SIP BYE message to the UE. 

8.2.6.5 Procedures at the PSS Adapter 

8.2.6.5.1 UE-initiated PSS streaming session teardown 

Upon receipt of a SIP BYE message from the SCF the PSS adapter shall send a RTSP TEARDOWN message to the 
PSS Server. 

Upon receipt of a RTSP 200 OK message from the PSS server, the PSS adapter shall send a SIP 200 OK message to the 
SCF. 

The PSS Adapter shall not close the RTSP session to the PSS Server on receipt of a TCP close, but waits until it has 
received the SIP BYE message in step 4 of clause 8.2.6.1.1. 
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8.2.6.5.2 SCF-initiated PSS streaming session teardown 

Upon receipt of the SIP BYE message, the PSS adapter sends the RTSP TEARDOWN message to the PSS server. Upon 
receipt of the RTSP 200 OK message from the PSS server, the PSS adapter sends the SIP 200 OK to the SCF. 

8.2.6.5.3 PSS adapter-initiated PSS streaming session teardown 

The PSS adapter sends the RTSP TEARDOWN to the PSS server. Upon receipt of the RTSP 200 OK, the PSS adapter 
sends the SIP BYE messge to the SCF. 

8.2.6.6 Procedures at the PSS Server 

Upon receipt of a RTSP TEARDOWN from the PSS adapter, the PSS server shall stop still on-going RTP transmissions 
and send a RTSP 200 OK message to the PSS adapter. 

8.2.7 Supported procedures 

Clause 8.2 specifies IMS initiated and controlled PSS streaming sessions. Protocols and procedures as defined in 3GPP 
TS 26.234 [8] are supported including 

• Fast content switching and start-up (clause 5.5). In the case of fast content start-up, the pipelining takes place 
between the PSS adapter and the PSS server. 

• Time-shifting support (clause 5.6) 

• RTP and RTCP extensions (clause 6.2.3) 

• Adaptation of continuous media (clause 10) 

• Quality of Experience reporting (clause 11). 



8.3 MBMS Streaming 

8.3.1 MBMS Media codecs and formats 

MBMS Media codecs and formats defined in 3GPP TS 26.346 [11] are applicable to the present document for IMS 
initiated and controlled MBMS User service. 

8.3.2 Procedure for providing missing parameters before session 
initiation 

8.3.2.1 Procedures at the UE 

If the UE does not have the all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS 

message. 

The "Request-URI" is related to the MBMS service that the user wants to activate. The "Request-URI" shall be 
composed of a user and domain part as defined as follows: 

The user part contains the serviceld. The serviceld shall be globalServicelD defined in [27] or serviceld defined 
in [1 1], which is retrieved from service selection information. 

The domain part is the Service Provider domain name, obtained from SSF. 

The TO header shall contain the same URI as in the "Request-URI" parameter. 

The FROM header shall indicate the public user identity of the user. 
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Upon reception of the 200 OK including service access information encapsulated in multipart/MIME, the UE shall 
initiate MBMS session as described in clause 8.3.3. 



8.3.2.2 



Procedures at the SCF 



When receiving the SIP OPTIONS message, the SCF shall examine the serviceld present in the user-part of the TO 
header and lookup the requested User Service Description information. 

The SCF shall answer with the user service description information of the content delivery channel (encapsulated in 
multipart/MIME) as requested by the serviceld. 

8.3.3 MBMS Streaming Session initiation 
8.3.3.1 General description 
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Figure 15: MBMS Streaming Session Initiation 

It is assumed that the UE has already received the MBMS USD containing the SDP and associated fragments for the 
service from the SSF before initiating the MBMS session. 

Step 1, 2: UE initiates a SIP INVITE message to SCF, indicating which MBMS Streaming User Service the 

user has chosen. 

Step 3, 4: SCF responds UE with a SIP 200 OK message when the SIP INVITE is successfully handled. The 

SIP 200 OK contains an SDP files containing the Multicast address of the service. The UE then 
activates the MBMS bearers either using the MBMS Broadcast Service Activation procedure [4] 
or the MBMS Multicast Service Activation Procedure [4]. 

Step 5: The UE can start receiving the MBMS Streaming session data when transmitted by the BM- 

SC.UPF. 

The construction of the SDP is not affected by the use of MBMS stream bundling, see section 8.2.2 of [1 1], nor are any 
of the procedures. 

8.3.3.2 Procedures at the UE 

The UE shall support the procedures specified in TS 24 229 [7] for originating sessions. 
The UE shall generate an initial INVITE request: 

• The Request-URI in the INVITE request shall be the well known PSI (Public Service Identifier) of the MBMS 
Service, i.e. Live Stream@<Domain name>. 

• The To header shall contain the same URI as in the Request-URI. 

• The From header shall indicate the public user identity of the user. 
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• The Recv-Info header shall be set to nil [42] . 

An SDP offer shall be included in the request. The SDP offer shall be done in accordance with the parameters received 
during UE service selection procedure and with media capabilities and required bandwidth available for the MBMS 
session. The SDP offer corresponds to the MBMS Streaming Session. See 3GPP TS 26.346 [11], clause 8.3.1. . The 
SDP offer at media level shall include the following elements: 

• The m-line(s) shall be set to the media parameters retrieved via service selection procedures for the requested 
MBMS service. 

• The c-line(s) shall be set according to the multicast address retrieved via service selection procedures for the 
requested MBMS service. 

• An a=mbms_service:MBMS_ServiceId line to indicate the MBMS service which the UE intends to initiate first. 
The MBMS_ServiceId shall be globalServicelD defined in [27] or serviceld defined in [11], which is retrieved 
from service selection information. 

• The a-attribute shall be set to the value of "recvonly". 

Once the UE receives the SIP response, the UE shall examine the media parameters in the received SDP, and initiate the 
MBMS channel according to the a=mbms_service line. It can activate the corresponding MBMS User Service as 
described in the USDs. MBMS User Service reception initiation may correspond to the MBMS Broadcast Mode 
activations as described in 3GPP TS 23.246 [4], clause 8.12 or the MBMS Multicast Mode activation procedure as 
described in 3GPP TS 23.246 [4], clause 8.2. 

8.3.3.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. The corresponding PCC procedures 
are performed as described in clause 9. 

8.3.3.4 Procedures at the SCF 

The SCF shall support the procedures specified in TS 24.229 [7] applicable to an AS acting as a terminating UA. 

Upon receipt of SIP INVITE request, the SCF shall perform service authorization procedures to check the service rights 
of requested MBMS service according to the user subscription information. See clause 10.4. 

The SCF shall examine the SDP parameters in the SDP offer. 

• It shall examine the a=mbms_service parameter. This parameter contains the channel the UE intends to 
join. If the mbms_service parameter does not point to a channel that the UE is allowed to join the SCF 
shall not accept the offer and shall answer with a 403 error code. 

• It shall examine the c-line(s) to determine that it is a multicast session. It may also check that it corresponds to 
the mbms_service parameter. If not, the SCF shall answer with an 403 error code. 

If the SDP parameters are examined successfully, the SCF shall answer with a SIP 200 OK, indicating the SDP answer 
as follows: 

• The c-lines and m-lines shall be identical to ones indicated in the SDP offer. 

• It shall include an a=sendonly attribute. 

The SIP 200 OK shall indicate the supported Info Packages in the Recv-Info header (Content Reporting) [42]. 

8.3.3.5 Procedures at the BMSC.UPF 

The MBMS session is already ongoing at the BMSC.UPF. No specific action is required. 
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8.3.4 MBMS content switching 



8.3.4.1 



General Description 



It is assumed that MBMS streaming reception is already active and a stream is delivered to the UE via MBMS. In case 
of MBMS content switching, the UE tunes into a new content channel e.g. in case of MBMS multicast mode the UE 
leaves a multicast channel and joins another one. 

The UE should sent a SIP INFO Message with the included Info Package (Content Reporting) to inform the SCF about 
which channel is being received unless the SCF prohibits it. A timer is started with a preconfigured value with default 
value of 10 seconds, when the channel switch is executed. After timer expiration the SIP INFO message is sent. 
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Figure 16: MBMS content switching reporting 



The UE sends content switching information to the SCF. 

The content switching information may include the serviceld after switching. The SCF may utilize the content 
switching information for statistical or charging purposes etc. 

If the SCF does not want to receive content switching information anymore or would like to start content switching 
reporting, the SCF should send a SIP UPDATE message to the UE with the Recv-Info header set appropriately. 
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Figure 16a: MBMS content switching reporting update 

8.3.4.2 Procedures at the UE 

The UE performs MBMS content switching according to the deactivation/activation procedures defined in [4]. 
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Upon identification of a successful content switch, the UE starts the content switching timer for a particular session. If 
another content switch occurs during the life of the timer, the timer is restarted. If the session is terminated during the 
life of the timer, the timer is stopped. After timer expiration, the UE should send a SIP INFO message with the Info 
Package (Content Reporting) to the SCF. The Content Reporting Info Package shall contain an XML document as 
defined in Annex D and Annex F. 

• ImsPssMbmsCommand shall be set to "MbmsSwitch"; 

• Serviceld shall be set to the value of the new channel. If the OMA BCAST Service Guide [27] is used, this 
shall be set to Global Service ID, otherwise shall be set to the MBMS User Service Description serviceld. 

• Programmeld may be present and if present shall be set to the identifier of the current programme of the 
new channel. If the OMA BCAST Service Guide [27] is used, this shall be set to service Name. 

• DateTime shall be set to the date & time of the channel switch. 

The Content-Type header shall be set to "application/3gpp-ims-pss-mbms-command +xml". 

After receiving a SIP UPDATE message from the SCF, the UE shall dependent on the Recv-Info header, stop or start 
the content switching reporting. 

8.3.4.2 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.3.4.3 Procedures at the SCF 

Upon receipt of a SIP INFO message the SCF shall send a SIP 200 OK to the UE. 

If the SCF does not want to receive content switching information anymore, it should send a SIP UPDATE message 
with the Recv-Info header set to nil. 

If the SCF decides to start content switching reports, the SCF should send a SIP UPDATE message with the Recv-Info 
header set to Content Reporting to the UE. 

8.3.4.4 Procedures at the BMSC.UPF 

The BMSC.UPF transmits the RTP flows, and is not involved in the reporting of content switching information. 

8.3.5 MBMS Streaming Session Teardown 
8.3.5.1 General Description 
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Figure 17: MBMS Streaming Session Termination 

UE receives Streaming content from the BM-SC.UPF. 
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Step 2, 3: UE initiates a SIP BYE message to SCF, indicating which MBMS Streaming session to close. 

Step 4, 5: SCF responds UE with a SIP 200 OK message when the SIP BYE is successfully handled and 

session terminated. At this stage, the UE can stop receiving the MBMS Streaming session. 

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5. The deactivation is 
either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS Multicast Mode 
deactivation procedure (3GPP TS 23.246 [4]). 

8.3.5.2 Procedures at the UE 

The UE shall send a SIP BYE to the SCF. 

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5 of clause 8.3.5.1. The 
deactivation is either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS 
Multicast Mode deactivation procedure (3GPP TS 23.246 [4]). 

8.3.5.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.3.5.4 Procedures at the SCF 

The SCF responds to the UE with a SIP 200 OK message after handling of the SIP BYE message. 

8.3.5.5 Procedures at the BMSC.UPF 

The BMSC.UPF is acting as described in 3GPP TS 23.246 [4]. 

8.4 Combined PSS and MBMS Streaming 

8.4.1 Introduction 

Combined PSS and MBMS streaming is important to ensure a consistent user experience. An UE may switch between 
one and the other depending on certain circumstances, e.g. changing between a PSS and MBMS coverage etc., or 
triggered by specific user action, e.g. trick play, etc. 

It is assumed that the UE has an already established PSS or MBMS session and is capable of switching to the other 
delivery method. 

Clause 8.4.2 gives the different cases and scenarios for switching between PSS and MBMS . 

8.4.2 PSS - IVIBIVIS Switching 

In the case of hybrid PSS-MBMS switching, it is distinguished between: 

(a) switching from MBMS streaming to PSS streaming: 

• Without channel change e.g. when a user is viewing an MBMS user service and moves out of MBMS 
coverage, or the user initiates trick play mode action, etc. 

• With channel change e.g. changing to a channel only available on PSS. 

(b) switching from PSS streaming to MBMS streaming: 

• Without channel change e.g. the user returns back from trick play mode to a normal MBMS user service, etc. 

• With channel change e.g. changing to a channel available on MBMS. 
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8.4.3 Switching from MBMS streaming to PSS streaming 

According to clause 8.3.3 an MBMS streaming session was initiated and the UE is receiving the MBMS session from 
the BM-SC.UPF. 

In order to switch from MBMS to unicast reception of a stream via PSS e.g. for allowing trick play mode, a SIP Re- 
INVITE is issued by the UE. An SDP offer and Request-URI shall be included according to clause 8.2.3. 

After receiving the 200 OK, the UE leaves the multicast channel and starts playback. 
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Figure 18: IMS Hybrid PSS-MBMS-to-PSS content switching 



8.4.3.1 



Combined Session establishment 



8.4.3.1.1 



Procedures at the UE 



When the UE switches from an MBMS User Service to a PSS user service, the UE sends a session modification request, 
i.e. SIP re-INVITE, with an SDP Offer and Request-URI. 

The Request-URI is related to the PSS session that the user wishes to activate. The Request-URI shall be composed of a 
user and domain part as defined in clause 8.2.3.2. 

The SDP offer shall include previously negotiated media descriptions with the port set to zero and two or more 
additional media descriptions: one for media control channel (i.e. RTSP control channel) and one or more for media 
delivery channel (i.e. delivery channel for the unicast streams). 

The RTSP control media descriptor shall follow TS 24.229 [7]. The SDP offer for media delivery shall be identical to 
the previous SDP offer done for broadcast in term of codecs and transport protocol. 

The UE may record the media offset for the MBMS user service. 
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When receiving SIP 200 OK response, the UE shall setup a media control channel with the PSS Adapter, and setup a 
media delivery channel with PSS Server according to the SDP answer. The UE shall send RTSP PLAY message to start 
the delivery of the media streams. 

8.4.3.1 .2 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.4.3.1.3 Procedures at the SCF 

When receiving the SIP modification request, the SCF will determine if the programme currently broadcasted has 
MBMS to PSS switching support. 

NOTE: The SCF may determine whether the SIP modification request is for MBMS to PSS switching according 
to the addition of the RTSP media control channel or unicast media delivery channel in the SDP offer. 

If MBMS to PSS switching is not available for the UE, the session modification is rejected and the old MBMS session 
(along with the previous reserved resources) is maintained. 

If MBMS to PSS switching is available for the UE, the SCF acting as a B2BUA, shall: 
o Handle the SIP modification request as defined in clause 8.2.3.4; 

o If the Request-URI contains a content identifier in the user part and a domain name in the domain part, the 
SCF shall select a suitable PSS adapter and generate a SIP INVITE request to the selected PSS adapter. 
The To header of the SIP INVITE request shall contain the same content identifier as in the Request-URI 
of the SIP modification request received from the UE; 

o Send the SIP INVITE request to the PSS Adapter with the SDP parameters for the content control channel 
of RTSP, and for the media delivery channel of unicast streams. The SCF shall precise the content 
identifier in the user part of the Request-URI. 

When sending the SIP INVITE message to PSS Adapter, SCF shall follow the procedures defined in TS 24.229 [7] 
concerning the AS acting as B2BUA. 

8.4.3.1.4 Procedures at the PSS Adapter 

When receiving a SIP INVITE request from SCF, as well as receiving RTSP 200 OK message from PSS Server, the 
PSS Adapter shall conform to clause 8.2.3.5. 

Prior to replying, the PSS Adapter uses real time to calculate the media offset for the MBMS user service when replying 
with the offered media. 

When receiving RTSP message from UE, the PSS Adapter shall conform to clause 8.2.4.2. 

8.4.3.1 .5 Procedures at the PSS Server 

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8]. 

8.4.3.2 Combined session teardown 

The combined session teardown shall conform to clause 8.2.6. 

8.4.4 Switching from PSS streaming to MBMS streaming 

According to clause 8.2.2 a PSS streaming session was initiated and the UE is receiving the PSS session from the PSS 
server. 

In order to switch from PSS to MBMS reception of a stream, a SIP Re-INVITE is issued by the UE and sent to the SCF. 
The SCF shall act as a B2BUA, and send a SIP BYE messge to PSS Adapter to terminate the SIP session between them. 
The PSS Adapter shall send a RTSP TEARDOWN messag to PSS Server to release the RTSP session. 
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Once the UE receives the SIP 200 OK response, it can activate the corresponding MBMS User Service as described in 
the SDP as defined in clause 8.3.3.2. 

After switching to MBMS reception, the PSS session shall be terminated. 
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Figure 19: IMS PSS-to-MBMS content switching 



8.4.4.1 



Combined Session establishment 



8.4.4.1.1 



Procedures at the UE 



When the UE switches from a PSS User Service to an MBMS user service, the UE sends a session modification request, 
i.e. SIP re-INVITE, an SDP offer shall be included according to clause 8.3.3. The SDP offer for media delivery shall be 
identical to the previous SDP offer done for PSS in term of codecs and transport protocol. 

Once the UE receives the SIP 200 OK response, it can activate the corresponding MBMS User Service as described in 
the SDP as defined in clause 8.3.3.2. MBMS User Service reception initiation may correspond to the MBMS Broadcast 
Mode activation procedure as described in 3GPP TS 23.246 [4], clause 8.12 or the MBMS Multicast Mode activation 
procedure as described in 3GPP TS 23.246 [4], clause 8.2. 

8.4.4.1 .2 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

8.4.4.1.3 Procedures at the SCF 

When receiving the SIP modification request, the SCF will determine if the content currently delivered has PSS to 
MBMS switching support. 
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If PSS to MBMS switching is not available for the UE, the session modification is rejected and the old PSS session 
(along with the previous reserved resources) is maintained. 

If PSS to MBMS switching is available for the UE, the SCF shall act as a B2BUA, and send a SIP BYE message to the 
PSS Adapter to terminate the SIP session between them. When sending the SIP BYE message to PSS Adapter, SCF 
shall follow the procedures defined in TS 24.229 [7] concerning the AS acting as B2BUA. 

Once receiving a SIP 200 OK message from PSS Adapter, SCF sends a SIP 200 OK message to UE with a SDP answer 
as defined in clause 8.3.3.4. 

8.4.4. 1 .4 Procedures at the PSS Adapter 

When receiving a SIP BYE message from SCF, as well as receiving RTSP 200 OK message from PSS Server, the PSS 
Adapter shall conform to clause 8.2.6.5. 

8.4.4.1 .5 Procedures at the PSS Server 

The procedures at the PSS Server shall conform to those defined in 3GPP TS 26.234 [8]. 

8.4.4.2 Combined session teardown 

The combined session teardown shall conform to clause 8.3.5. 



Policy and charging control 



9.1 General 

For the purpose of the present specification, the policy and charging control (PCC) is according to 3GPP TS 23.203 
[12]. This clause is relevant when PCC is present. However, IMS based PSS and MBMS User Services can be realized 
without PCC. When PCC is not present, the UE is responsible for allocation of the resources based on Session 
Description information. 

Service subscription control is performed by the SCF at registration and at PSS and MBMS session initiation. 

QoS control is different for PSS and MBMS User Services. 

9.2 QoS control 

The P-CSCF is used as the Application Function in the PCC architecture. The PCRF decides how policy control of the 
QoS is performed for IMS initiated and controlled PSS and MBMS User Service. 

In case of PSS, the PCRF shall use the SDP received from the P-CSCF during session establishment to calculate the 
proper QoS authorization. The way the QoS is enforced in this architecture is defined in 3GPP TS 23.203 [12]. 

In case of MBMS, the PCRF shall not initiate the establishment of a specific bearer. 
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Figure 20: PSS QoS Policy Control 

NOTE: The sequence shown is simplified and does not e.g. show session progress messages and the ACK 
message from the UE in response to the reception of 200 OK. 

The PSS case of QoS control is shown on figure 20. The appropriate existing bearers are used or new required bearers 
are allocated. Network initiated bearer control and UE initiated bearer control are possible. When receiving the final 
SDP, the UE shall initiate the establishment of the required bearers unless a network initiated bearer allocation 
procedure is already ongoing, or the UE has been configured to use network initiated resource control. 



1 Security Procedures 



10.1 General 

Different security procedures apply for IMS, MBMS and PSS. 

IMS level authentication and access security is performed during IMS registration in accordance to [7]. 
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PSS-Only: PSS defines an optional confidentiality protection of individual RTP payloads used in a streaming session. If 
PSS confidentiality protection as defined in 3GPP TS 26.234 [8], Annex K. is used, then the terminal initiates the 
GAA/GBA Bootstrapping procedure 3GPP TS 33.220 [26] after a successful IMS registration and Service discovery. 

MBMS-only and combined PSS/MBMS service offerings: MBMS security is based on GAA/GBA [26]. The 
GAA/GBA Bootstrapping procedure is initiated by the UE after a successful IMS registration and Service discovery. It 
is necessary before any service description retrieval and session initiation. 

GBA (see 3GPP TS 33.220 [26]) is used to generate a master key Ks from which NAF specific keys (e.g. Ks_NAF for 
ME based key management) can be derived when needed. It is also used to authenticate the user for signaling that is not 
performed via the IMS core network (e.g. HTTP based service description retrieval). 

GBA is also used to generate and provision the NAF keys (e.g. Ks_NAF for ME based key management) - which is the 
Long Term Key that is used in content encryption/decryption procedures - and the B-TID - which is the corresponding 
bootstrapping transaction identifier. 
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Figure 21 : GBA/GAA Bootstrapping procedure 

Figure 21 illustrates the GBA/GAA bootstrapping procedure. The following steps are performed. See [26] for details: 

• The UE sends a request to the BSF with its IMPI as User ID. The UE discovers the address of the BSF as 
specified in [26]. 

• The BSF then acquires one Authentication Vector from the HSS and may acquire the User"s GUSS (GBA 
User Security Settings) and forwards the RAND and AUTN to the UE in the HTTP 401 message. 

• The UE checks AUTN to verify that the challenge is from an authorised network. 

• The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF. 

• The BSF authenticates the UE by verifying the Digest AKA response. The BSF shall send a 200 OK message, 
including a B-TID, to the UE to indicate the success of the authentication. 

If UICC based MBMS key management is required, then USIM shall be used. Otherwise either USIM or ISIM may 
be used. 

NOTE: The reason for this is that UICC based MBMS key management is currently specified only for USIM. 

10.2 Secure Service Description Retrieval 

The Service Description retrieval procedure allows the UE to acquire the necessary information to select and initiate 
PSS and/or MBMS sessions using IMS procedures. See clause 7 for more details on this procedure. 
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Figure 22: Service Description retrieval with authentication 

Figure 22 describes the Service Description retrieval procedure with authentication. 

The UE requesting a service description towards the SSF (acting as a GBA Network Application Function (NAF)) shall 
include the B-TID corresponding to the Ks established during the bootstrapping procedure. When the SSF receives the 
service description request, it shall trigger an authentication request towards the BSF to acquire the NAF keys ( e.g. 
Ks_NAF for ME based key management) of the user if the SSF does not already have the NAF keys available. The SSF 
shall trigger HTTP digest authentication procedure towards the UE in accordance with 3GPP TS 33.222 [20]. 

The SSF shall use TLS to encrypt the Service Description during retrieval. 

1 0.3 PSS Authentication and Content encryption 

Void (TBD). 

1 0.4 IVIBIVIS Security procedures 

The IMS based MBMS user service security procedures shall fulfil the key management procedures defined in TS 
33.246 [5], including MSKprocedures in clause 6.3.2 of TS 33.246 [5], and MTK procedures in clause 6.3.3 of TS 
33.246 [5]. The MSK procedure further includes MBMS user service registration procedure, deregistration procedure, 
MSK request procedure and MSK delivery procedure. 

Clause 10.4.1 describes MBMS security procedures where HTTP is used as described in TS 33.246 [5], and 
BMSC.UPF acts as NAF to interact with BSF and derives security keys. 

Clause 10.4.2 describes MBMS security procedures where SIP is used and SCF act as a NAF to interact with BSF and 
derives security keys. 

The procedures according to clause 10.4.1 and clause 10.4.2, respectively, are alternatives for MBMS security 
procedures. They are equal in terms of security provision. The UE shall support both alternatives for MBMS security 
procedures. The UE is informed about the supported MBMS security procedure by retrieval of the service attachment 
information from the SDF as defined in Annex H. 

1 0.4.1 HTTP based IVIBIVIS security procedure 

Clause 10.4.1 describes MSK procedures, and clause 10.4.2 describes MTK procedures. 
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10.4.1.1 MS K procedures 

The IMS based MBMS user service registration procedure, deregistation procedure, MSK request procedure and MSK 
delivery procedure are defined in clause 10.4.1 to 10.4.4 respectively. 



10.4.1.1.1 



IMS based MBMS user service key registration procedure 
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Figure 23: Security procedures for IIUIS based lUISIUIS user service 



10.4.1.1.1.1 Procedures at the UE 

When the user indicates to view an MBMS user service, the UE shall send a SIP INVITE message to SCF via IM CN 
Subsystem, The SIP INVITE message shall include MBMS Service ID to indicate which service the user intends to 
watch, as defined in clause 8.3.3.2, and a P- Preferred -Identity header with the value set to the desired user public 
identity. 

After receiving a SIP 200 OK message, the UE shall perform MSK registration procedure as defined in clause 6.3.2.1a 
of TS 33.246[5]. The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall conform to TS 
33.246[5], and include an HTTP X-3GPP- Intended -Identity header as defined in TS 24.109 [22] with the value set to 
the user"s public identity. 

10.4.1.1.1.2 Procedures at the IM CN Subsystem 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

10.4.1.1.1.3 Procedures at the SCF 

Upon receipt of a SIP INVITE request, the SCF shall perform service authorization procedure as defined in clause 

8.3.3.4. 

After successfully service authorization, the SCF shall send an Authorization Notification HTTP POST message to 
BMSC.UPF. The HTTP POST message shall be populated as follows: 

the HTTP version shall be 1.1 which is specified in RFC2616 [34]; 
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the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "authorize", i.e. Request-URI 
takes the form of "/keymanagement?requesttype= authorize"; 

- the HTTP X-3GPP-Asserted-Identity header shall be the IMPU of the user retrieved from the SIP INVITE 
message. 

the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-authorize-nxml". 

the HTTP payload shall contain request including the authorized MBMS Service ID Serviceld carried in the SIP 
INVITE message; 

After receiving an authorization acknowledgement, the SCF shall send a SIP 200 OK message to the UE as defined in 
clause 8.3.3.4. 

10.4.1 .1 .1 .4 Procedures at the BM-SC. UPF 

Upon receiving an Authorization Notification message from SCF, the BMSC.UPF shall store the received message, and 
respond an Authorization Acknowledgment HTTP 200 OK message. 

Upon receiving MSK registration message from a UE, the BMSC.UPF shall act as a NAF and perform GBA usage 
procedure with BSF to get GBA keys to derive MUK. The MUK is used for BM-SC.UPF to protect the transfer of 
MSK. 

The BMSC.UPF shall authorize the UE according to the stored information. The BMSC.UPF shall send MSKs to the 
UE corresponding to the service IDs in the received message via MIKEY, as defined in clause 6.3.2.1a of TS 33.246[5]. 

1 0.4.1 .1 .2 IMS based MBMS user service key deregistration procedure 

The IMS based MBMS user service MSK request procedure conforms to clasue 6.3.2. IB of TS 33.246[5]. Additionaly, 
The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall include an HTTP X-3GPP- Intended - 
Identity header as defined in TS 24.109 [22] with the value set to the user"s public identity. 

1 0.4.1 .1 .3 IMS based MBMS user service MSK request procedure 

The IMS based MBMS user service MSK request procedure conforms to clasue 6.3.2.2 of TS 33.246[5]. Additionaly, 
The HTTP POST message initiated by the UE and addressed to BMSC.UPF shall include an HTTP X-3GPP- Intended - 
Identity header as defined in TS 24.109 [22] with the value set to the user"s public identity. 

1 0.4.1 .1 .4 IMS based MBMS user service MSK delivery procedure 

The IMS based MBMS user service MSK delivery procedure conforms to clause 6.3.2.3 of TS 33.246[5]. 

10.4.1.2 MTK procedure 

The IMS based MBMS user service MTK procedure conforms to clause 6.3.3 of TS 33.246[5]. 

1 0.4.2 SIP based MBMS security procedures 
10.4.2.0 General 

Clause 10.4.2 describes an alternative to clause 10.4.1 for MBMS security procedures, where the NAF for the MBMS 
User Services is implemented in the SCF and interacts with the BSF. The procedures apply for both ME and UICC 
based key management. 

The MBMS Security specification 3GPP TS 33.246 [5] defines a set of security procedures. The following list 
describes how these procedures are applied in the context of IMS based MBMS user services when using SIP based 
MBMS security procedures. 

'MBMS User Service Registration procedure'. 
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In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 

10.4.2.1 in the present document. 

'MBMS User Service Deregistration procedure'. 

In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 
10.4.2. 1 A in the present document. 

'Basic MSK request procedure'. 

In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 

10.4.2.2 in the present document. 

'Missed key update procedure'. 

This procedure is equivalent to Basic MSK request procedure. 

'BM-SC solicited pull procedure'. 

In the context of SIP based MBMS security procedure, this procedure is applied as specified in clause 
10.4.2.4 in the present document. 

- 'MSK delivery procedure' 

In the context of SIP based MBMS security procedure, this procedure is applied as defined TS 33.246 [5] 
with exception that SCF FQDN is sent instead of BM-SC FQDN. 

'MTK update procedure' 

In the context of SIP based MBMS user services this procedure is applied as defined TS 33.246 [5]. 



10.4.2.1 SIP based MBMS User Service Registration 

This procedure is used to register a UE with one or more MBMS User Services. 

It is assumed that the UE has received the service description (cf clause 10.2). The service description includes, e.g. 
the service protection description. The service protection description is similar as defined in 3GPP TS 33.246 [5] with 
the following exception: the FQDN of the BM-SC is not included in the service protection description. Instead, the 
service protection description for the service shall include an FQDN belonging to the SCF as the SCF acts as a NAF. 

NOTE 1 : This is to ensure consistent NAF key derivation in the UE and in the BSE as the SCF acts as a NAF and 
as the FQDN of the NAF is used as input in NAF key derivation. 

In case more than one BM-SCs are connected to the SCF, the SCF shall locally associate a different one of its FQDNs 
to each connected BM-SC. As there is one NAF FQDN indicated in the service protection description for each service, 
the SCF (NAF) will know from the userServiceld indicated by the UE which NAF FQDN to be used for NAF key 
derivation. 

NOTE 2: This will ensure that each connected BM-SC will get different NAF key, and consequently will get 

different MUK. GBA TS 33.220 [26] allows the NAF to be known in DNS under several FQDNs if it is 
ensured that the correct NAF FQDN is used in NAF key derivation. 

It is also assumed that the UE has been registered and authenticated to IMS and the SIP procedures are protected 
according to 3GPP TS 33.203 [31], and that the UE has run GBA bootstrapping with the BSE as defined in 3GPP TS 
33.220 [26]. It is also assumed that the network interfaces are protected with Network Domain Security (NDS/IP) as 
defined in 3GPP TS 33.210 [32]. 
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Figure 24: SIP based MBMS User Service Registration 

The procedure is as follows (cf. figure 24 which is simplified as it does not show all parameters): 

- The UE sends a SIP INVITE to the SCF via the IM CN subsystem. The INVITE indicates SCF in the Request- 
URI and the message includes the identities of the requested MBMS user services (userServicelds) for which the 
UE wants to register and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE. The 
XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the 
B-TID is defined in annex I.l. 

The SCF receives the IP address of the UE and the asserted identitie(s) of the UE from the headers of the SIP 
INVITE message. The SCF performs a check based on stored subscription information whether the UE is 
authorized to access the requested MBMS user services. If yes, the procedure continues. If not, the procedure is 
terminated. 

If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the 
SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined 
in 3GPP TS 33.220 [26]. The NAF-Id which the SCF uses over Zn is constructed from the NAF FQDN indicated 
in the service protection description for this service and Ua security protocol identifier specified in 3GPP TS 
33.220 [26]. As there is one NAF FQDN indicated in the service protection description for each service, the SCF 
will know from the userServiceld indicated by the UE which FQDN to be used as NAF FQDN. Upon receiving 
the NAF keys from the BSF, the SCF derives MBMS User Key (MUK) as defined in TS 33.246 [5]. 
If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall 
response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA 
bootstrapping. 

- The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows: 
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the HTTP version shall be 1.1 which is specified in RFC 2616 [34]; 

the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-register", i.e. 
Request-URI takes the form of "/keymanagement?requesttype= sip-based-register "; 

the SCF may add additional URI parameters to the Request-URI; 

X-3GPP-Asserted-Identity header which includes the identitie(s) of the UE; 

the HTTP header Content-Type shall be the MIME type of the payloads; 

the HTTP payload shall contain an XML document including a list of one or more userServicelds of MBMS 
User Services to which the UE wants to register, IP address of the UE, MBMS user key (MUK), lifetime of 
MUK, NAP FQDN and B-TID. NAF FQDN and B-TID are included as they are further included in the 
MIKEY MSK messages from the BM-SC to the UE to identify the used MUK (i.e. NAF key). The XML 
schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for carrying 
IP address, MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2. 

- the SCF may add additional HTTP headers to the HTTP POST request. 

Upon receiving the HTTP POST message, the BM-SC checks that the HTTP POST is valid, and extracts the 
request for further processing. As the HTTP POST message came from SCF with asserted identitie(s), the BM- 
SC does not need to authenticate the UE as the UE has been authenticated by the IMS. Also, the HTTP POST 
message also implicitly indicates to the BM-SC that the SCF has authorized the UE to register to the indicated 
MBMS User Service(s). 

The BM-SC stores the received information and returns HTTP 200 OK to the SCF. The BM-SC shall populate 
HTTP response as follows: 

- the HTTP status code in the HTTP status Une shall be 200; 

- the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-register- 
response-Hxml "; 

the HTTP payload shall contain an XML document including a list including one status code for each MBMS 
User Service. The XML schema of the payload is the same that is used for MBMS Registration in 3GPP TS 
33.246 [5] and it is specified in 3GPP TS 26.346 [11]. 

- Upon receiving the HTTP 200 OK., the SCF then includes the XML body from the HTTP 200 OK message into 
a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem. 

Upon receiving the 200 OK the UE derives NAF keys corresponding to the NAF-Id. The NAF-Id is constructed 
from the NAF FQDN indicated in the service description and Ua security protocol identifier specified in 3GPP 
TS 33.220 [26]. The UE derives MBMS User Key (MUK) from the NAF key as defined in 3GPP TS 33.246 [5]. 

BM-SC can now start sending MIKEY MSK messages (protected with MUK) to the UE as defined in 3GPP TS 33.246 
[5]. In MIKEY MSK messages the BM-SC shall include the NAF FQDN and B-TID received from the SCF as they are 
used to identify the used MUK (i.e. NAF keys). 

10.4.2.1a SIP based MBMS User Service De-registration 

This procedure is used to de-register a UE from one or more MBMS User Services. 

The same assumptions apply as in SIP based MBMS User Service Registration in clause 10.4.2.1. 
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Figure 24a: SIP based MBMS User Service De-registration 

The procedure is as follows (cf. figure 24a which is simplified as it does not show all parameters): 

- UE sends a SIP re-INVITE to the SCF via the IM CN subsystem. The re-INVITE indicates SCF in the Request- 
URI and the message includes the identities of the requested MBMS user services (userServicelds) from which 
the UE wants to de-register and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE.. 
The XML schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for 
the B-TID is defined in annex x. 1. 

The SCF receives the asserted identitie(s) of the UE from the headers of the SIP re-INVITE message. 

If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the 
SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined 
in 3GPP TS 33.220 [26]. The NAF-Id which the SCF uses over Zn constructed from the NAF FQDN indicated 
in the service protection description for this service and Ua security protocol identifier specified in 3GPP TS 
33.220 [26]. Upon receiving the NAF key from the BSF, the SCF derives MBMS User Key (MUK) as defined in 
3GPPTS 33.246 [5]. 

If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall 
response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA 
bootstrapping. 

- The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows: 

the HTTP version shall be 1.1 which is specified in RFC 2616 [34]; 

the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-deregister", i.e. 
Request-URI takes the form of "keymanagement?requesttype= sip-based-deregister"; 

the SCF may add additional URI parameters to the Request-URI; 

X-3GPP-Asserted-Identity header which includes the identities of the UE; 

- the HTTP header Content-Type shall be the MIME type of the payloads; 
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the HTTP payload shall contain the request an XML document including a list of one or more userServicelds 
of MBMS User Services from which the UE wants to deregister. If new N AF keys were created in the 
previous step, then the SCF shall also include MBMS user key (MUK), lifetime of MUK, NAP FQDN and 
B-TID. E.g. the BM-SC may send an MSK message to invalidate the MSKs in the UE as defined in 3GPP TS 
33.246 [5]. The XML schema for the Hst of MBMS user service IDs is defined in 3GPP TS 26.346 [11] and 
the XML schema for carrying MUK, MUK lifetime, NAP FQDN and BTID is defined in annex x.2; 

- the SCF may add additional HTTP headers to the HTTP POST request. 

- The BM-SC receives the HTTP POST message. The BM-SC checks that the HTTP POST is vahd, and extracts 
the request for further processing. As the HTTP POST message came from SCF with asserted identities, the BM- 
SC does not need to authenticate the UE as the UE has been authenticated by the IMS. 

The BM-SC returns HTTP 200 OK to the SCF. The BM-SC shall populate HTTP response as follows: 

- the HTTP status code in the HTTP status Une shall be 200; 

the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-register- 
response-Hxml". XML document is the same that is used for MBMS De-registration in 3GPP TS 33.246 [5] 
and it is specified in 3GPP TS 26.346 [11]; 

the HTTP payload shall contain a list including one status code for each MBMS User Service. 

- Upon receiving the HTTP 200 OK, the SCF then includes the XML body from the HTTP 200 OK message into a 
SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem. 

10.4.2.2 SIP based Basic MSK Request 

This procedure is used to by the UE to request one or more MSKs. 
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Figure 25: SIP based MBMS MSK request 

The same assumptions apply as in IMS based MBMS User Service Registration in clause 10.4.2.1. 

The procedure is as follows (cf figure 25 which is simplified as it does not show all parameters): 

- UE sends a SIP re-INVITE to the SCF via the IM CN subsystem. The re-INVITE indicates SCF in the Request- 
URI and the message includes a list of one or more Key Domain ID - MSK ID pair(s) of the MSKs that the UE 
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wants to receive and the bootstrapping transaction identifier (B-TID) in the body of the SIP INVITE. The XML 
schema for the list of MBMS user service IDs is defined in TS 26.346 [11] and the XML schema for the B-TID 
is defined in annex x. 1 . 

The SCF receives the asserted identitie(s) of the UE from the headers of the SIP re-INVITE message. The SCF 
performs a check based on stored subscription information whether the UE is authorized to receive the specified 
MSK(s). If yes, the procedure continues. If not, the procedure is terminated. 

If there is no B-TID stored for the UE or if the received B-TID is different than the one stored for the UE, the 
SCF runs GBA usage procedure with the BSF over Zn to fetch the NAF keys corresponding to the UE as defined 
in 3GPP TS 33.220 [26]. The NAF-Id which the SCF uses over Zn is constructed from the NAF FQDN indicated 
in the service protection description for this service and Ua security protocol identifier specified in 3GPP TS 
33.220 [26]. Upon receiving the NAF keys from the BSF, the SCF derives MUK from the NAF key as defined in 
3GPPTS 33.246 [5]. 

If the received B-TID is not valid or if the SCF desires the UE to make a new GBA bootstrapping, the SCF shall 
response to the UE with an appropriate error message. The error message will trigger the UE to run new GBA 
bootstrapping. 

- The SCF sends a HTTP POST message to the BM-SC. The SCF populates the HTTP POST as follows: 

the HTTP version shall be 1.1 which is specified in RFC 2616 [34]; 

the base of the Request-URI shall contain the full BM-SC key management URI (e.g. 
http://bmsc.homel.net: 1234); 

the Request-URI shall contain an URI parameter "requesttype" that shall be set to "sip-based-msk-request", 
i.e. Request-URI takes the form of "/keymanagement?requesttype= sip-based-msk-request"; 

the SCF may add additional URI parameters to the Request-URI; 

X-3GPP-Asserted-Identity header which includes the identities of the UE; 

the HTTP header Content-Type shall be the MIME type of the payloads; 

the HTTP payload shall contain a list of one or more Key Domain ID - MSK ID pair(s) of the MSKs that the 
UE wants to receive. If new NAF keys were created in the previous step, then the SCF shall also include 
MBMS user key (MUK), lifetime of MUK, NAF FQDN and B-TID. NAF FQDN and B-TID are included as 
they may be further included in the MIKEY MSK messages from the BM-SC to the UE, The XML schema 
for the Hst of Key Domain ID - MSK ID pair(s) is defined in 3GPP TS 26.346 [11] and the XML schema for 
carrying IP address, MUK, MUK lifetime, NAF FQDN and BTID is defined in annex x.2. 

the UE may add additional HTTP headers to the HTTP POST request. 

- The BM-SC receives the HTTP POST message. The BM-SC checks that the HTTP POST is vaHd, and extracts 
the request for further processing. As the HTTP POST message came from SCF with asserted identities, the BM- 
SC does not need to authenticate the UE as the UE has been authenticated by the IMS. Also, the HTTP POST 
message also implicitly indicates to the BM-SC that the SCF has authorized the UE to receive the specified 
MSK(s). 

The BM-SC stores the received information and returns HTTP 200 OK to the SCF. The BM-SC shall populate 
HTTP response as follows: 

- the HTTP status code in the HTTP status line shall be 200; 

the HTTP header Content-Type shall be the MIME type of the payload, i.e. "application/mbms-msk- 
response-Hxml" ; 

the HTTP payload shall contain a list including one status code for each MSK. The XML schema of the 
payload is the same that is used for MBMS MSK request in 3GPP TS 33.246 [5] and it is specified in 3GPP 
TS 26.346 [11]. 

- The SCF receives the HTTP 200 OK. The SCF then includes the XML body from the HTTP 200 OK message 
into a SIP 200 OK message and sends the SIP 200 OK message to the UE via the IM CN subsystem. 
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10.4.2.3 



Updating MUK 



The GBA session (i.e. key Ks derived NAF specific keys, e.g. MUK) has a limited lifetime. The GBA session may 
expire during service consumption. In this case the UE shall run GBA bootstrapping again to create a new Ks. The UE 
shall then re-register to the services with the SIP based MBMS registration procedure defined in clause 10.4.2.1 with re- 
INVITE and the new B-TID. This will create a new MUK in the UE and network. 

1 0.4.2.4 SIP based BM-SC solicited pull 

According to 3GPP TS 33.246 BM-SC solicited pull procedure is triggered by the BM-SC by sending an MSK message 
with a specific MSK-ID value. This will trigger the UE to perform MSK request. IMS based MBMS uses the BM-SC 
solicited pull procedure as defined in TS 33.246 to trigger the UE to perform SIP based basic MSK request procedure 
which is specified in clause 10.4.2.2. 



1 1 Blending of Presence and PSS/MBMS user services 



11.1 General description 



This clause describes the mechanisms that apply when IMS based PSS and MBMS user services are combined with 
presence service. 

The architecture and functional description of the presence service when used in relation to the IMS based PSS & 
MBMS services shall conform to [37]. 

The protocol details for the presence service when used in relation to the IMS based PSS & MBMS services shall 
conform to [36]. 

The following call flow gives a high-level description for presence service used in the context of IMS based PSS and 
MBMS. In this example, the UE 1 is the watcher and the UE 2 is the presentity. The UE 2 is in the UE I's list of 
contacts and wants to publish on-demand content currently watching. 
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Figure 26: High-level description for presence service used in the context of IMS based PSS and 

MBMS 
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1 . The UE 1 subscribes for presence information for a list of contacts which includes the UE 2, by sending a SIP 
SUBSCRIBE message to the Presence Server as defined in [36]. 

2. After having initiated the PSS or MBMS session, or after a content switching, the UE 2 decides to publish what 
content is being consumed. The UE 2 sends a SIP Publish message to the Presence Server, as defined in [36], including 
additional attributes specific to PSS and MBMS such as the content being consumed. 

3. On reception of the SIP Publish, the Presence server notifies the UE 1 of what the UE 2 is doing, by sending a SIP 
NOTIFY message as defined in [36]. 

1 1 .2 Procedures at the UE acting as presentity 

The UE acting as presentity may send a SIP PUBLISH in the following cases: 

- On receipt of a final SIP 200 OK concerning a PSS streaming session initiation procedure; 

- On receipt of a final SIP 200 OK concerning a MBMS streaming session initiation procedure; 

During a streaming session, the UE may also send a PUBLISH request after having performed content switching. This 
includes the cases of: 

- PSS content switching, 

- MBMS content switching, 

- Switching from PSS to MBMS streaming with channel change, 

- Switching from MBMS to PSS streaming with channel change. 



The content of the PUBLISH request shall be set as follows: 

- The request-URI, the To and the From headers shall be set to the public user identity of the user, 

- The Event header shall be set to the "presence" event package, 

- The content type shall be set to "application/pidf+xml" 

The SIP PUBLISH generated by the UE acting as presentity shall conform to [36]. 

The presence XML document included in the PUBLISH body shall conform to [36] and [37]. 

Additional elements specific to PSS and MBMS services shall be included in the XML document. In case of a Live TV 
service, these specific additional elements are the Live TV channel currently watched, and the current TV program. In 
case of an on-demand service, specific additional element is the on-demand content. 

The XML schema used when the presence documents are published by the UE is described in Annex E of [24], with the 
following conformity: 

- the "currentBCServicelD" refers to the LiveTV channel delivered in PSS or MBMS, 

- the "currentBCProgramID" refers to the currently watched program delivered in PSS or MBMS, 

- the "currentCoDContentID" refers to the currently watched on-demand content delivered in PSS. 

1 1 .3 Procedures at the UE acting as watcher 

The SIP SUBSCRIBE generated by the UE acting as a watcher shall conform to [36]. 

The UE acting as a watcher may then receive a SIP NOTIFY message including the content consumed by the UE acting 
as presentity. 



1 2 Networked Bookmark Service 

Bookmarking allows a user receiving a content item at an UE to mark a point in time in the streamed content which he 
can access at a later time. The content item is CoD delivered by a PSS server. 

The user can later retrieve the bookmark from any device on which he is registered. 
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12.1 Bookmarking Creation and Storage 

The call flow in Figure 27 depicts the sequence for creating a bookmark for a CoD item and storing it in the user"s 
service profile for later retrieval. 
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Figure 27: IMS-based CoD Bookmark creation and Storage 

The following is a brief description of the steps: 

1 . The UE has established a CoD session. At some point in time, the user decides he wants to create a bookmark. If 
the UE does not have the current play out position, it sends an RTSP GET-PARAMETER request to the PSS 
server to request it. 

2. The response to the RTSP GET-PARAMETER request is returned by the PSS server in an RTSP 200 OK. 

3. The UE sends to the IM CN Subsystem a SIP INFO Message that includes the info-event CoD-Bookmark 
package as well as the CoD content id. 

4. The IM CN Subsystem forwards the SIP INFO Message to the SCF. 

5. The SCF issues an XCAP request, on behalf of the user, to update the service profile with the CoD-Bookmark 
data. 

6. The Service Profile returns the response to the SCF. 

7. The SCF returns a SIP 200 OK to the IM CN Subsystem. 

8. The IM CN Subsystem forwards the SIP 200 OK to the UE. 



12.2 Bookmarking Retrieval 



Once a bookmark is created, a user can later retrieve the bookmark anytime, e.g. prior to or during PSS session 
establishment procedure, from any device on which he is registered. 
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Clause 12.2.1 depicts the bookmarking retrieval procedure which is independent to PSS session establishment 
procedure, and clause 12.2.2 depicts the bookmarking retrieval procedure during a PSS session establishment process. 

12.2.1 Bookmarking Retrieval independent to session establishment 

The call flow in Figure 28 depicts the bookmark retrieval procedure for retrieving bookmarks stored in the user"s 
service profile. 
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Figure 28: Bookmark retrieval independent to session establishment 

The following is a brief description of the steps: 

1. The UE issues an XCAP GET request to the Service Profile to request the bookmarks. 

2. The bookmarks are returned in an HTTP 200 OK response. 

12.2.2 Bookmarking Retrieval during session establishment 

The call flow in Figure 29 depicts the bookmark retrieval procedure for retrieving bookmarks stored in the user"s 
service profile during a PSS session establishment process. 
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Figure 29 Bookmark Retrieval during session establishment 

1 . The UE sends an SIP INVITE to the SCF via the IM CN Subsystem. 

2. The IM CN Subsystem fowards the SIP INVITE to the SCF. 

3. The SCF validates the SIP INVITE request, and checks the rights of user for the requested content by 
sending an XCAP GET with the user ID and content identifier to the Service Profile. 

4. The Service Profile authorizes the user, and returns the user"s service profile with the bookmark list if it is 
set before. Each bookmark in the list should contain at least the content ID and the time reference. 

5. The SCF selects the appropriate PSS Adapter for the requested content, and sends the SIP INVITE to the 
PSS Adapter via the IM CN Subsystem. The PSS Adapter then selects the PSS Server and sends the RTSP 
SETUP to the PSS Server. 

6. The PSS Server returns an RTSP 200 OK to PSS Adapter, which returns a SIP 200 OK to the SCF via the 

IM CN Subsystem. 

7. The SCF returns the SIP 200 OK to the UE via the IM CN Subsystem, with the bookmark list. 

8. The IM CN Subsystem forwards the SIP 200 OK to UE. 

9. The UE plays out the bookmark list to the user, and the user selects the bookmark from which they wish to 
start viewing the content. 



1 3 User generated content service 

This clause defines the provision and distribution procedures of user generated content (UGC) for IMS based PSS and 
MBMS User Services. 



ETSI 



3GPP TS 26.237 version 9.4.0 Release 9 



71 



ETSI TS 126 237 V9.4.0 (2010-10) 



User generated content refers to content that is provided by an UE e.g. video or audio captured by an in-built camera or 
microphone. In the following this UE is noted as providing UE, and the UE receiving UGC by PSS or MBMS is noted 
as receiving UE. 

The UGC provision procedure allows a providing UE to declare and upload/upstream UGC content to the network, 
which is defined in clasue 13.1. The UGC distribution procedrue allows a receiving UE to select and watch User 
Generated Content which is defined in clause 13.2. 

13.1 UGC content provision procedure 

UGC provision procecure is carried out in four steps as shown in figure 30: 



UE 




SSF 




IMCN 

Subsystem 




SCF 




UGC Reception 
Server 




































1. Declaration of UGC 
























2. Publication of UGC information by the providing UE 
























3. UGC creation session initiation 


















4. Publication of UGC information by the SCF 
















UGC creation session modification/termination 

1 
1 

































Figure 30 : IMS Based UGC Provision Procedures 

NOTE: The UGC reception server can be implemented independent to, or within PSS Server, or BMSC.UPF. 

Step 1: Declaration of UGC : 

The providing UE sends a UGC declaration request to the SCF. The SCF records the UGC information, generates a 
unique UGC content ID and sends a UGC declaration response with the content ID to the providing UE. 

NOTE: The content ID that should be used is out of scope of this release. 

Step 2: Publication of UGC information by the providing UE : 

The providing UE sends to the SCF a UGC description request including a UGC description, e.g. name, type, 
restriction, textual description, special group users etc. together with the UGC content ID. 

The SCF records the UGC description, establishes the relationship between UGC content ID and UGC description, and 
sends UGC description response to the providing UE. 

NOTE: Step 1 is always the first step. Step 2 may happen at any time during the UGC provision procedure and can be 
repeated during the lifetime of the content, e.g. for updating of the UGC description. 

NOTE: The messages supporting steps 1 and 2 may be embedded in the messages supporting step 3. 
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Step 3: Creation of UGC : 

User generated content could be provided for distribution by different means i.e. uploading and upstreaming from the 
providing UE. 

Uploading should be used for user generated content that is stored at the UE. For uploading, HTTP should be used. 
3GPP file format according to [39] should be supported. 

Upstreaming should be used for live content that is continuously generated during upstreaming. For upstreaming, 
multimedia telephony service over IMS (MTSI) as defined in [38] should be used. 

The SCF should signal the address of the UGC reception server to the providing UE. 

In case of uploading, a HTTP connection is established and UGC is uploaded to a UGC upload reception server. In this 
case the upload reception server must support HTTP. 

In case of upstreaming, the providing UE initiates a MTSI session and upstreams the UGC to the UGC upstreaming 
reception server. In this case, the upstreaming reception server must support MTSI specifications [38]. 

Step 4: Publication of UGC information by the SCF: 

The SCF establishes the relationship between UGC content ID, UGC description and optionally UGC location 
(address), and publishes the UGC description information. 

Step 4 may take place before, during or after step 3. In case of upstreaming, step 4 is carried out before step 3. 

The UE can modify or terminate the established UGC creation session later on. 

NOTE: Updating the SSF for UGC information from the SCF is required, but the method for achieving this is out 
scope of this specification. 



13.2 UGC distribution procedure 



The UGC reception server is responsible for repackaging and/or transcoding the uploaded or upstreamed content into 
such a form that can be served to legacy PSS servers and BMSCs. The UGC reception server is responsible for serving 
received UCG to legacy PSS Servers and BMSC in live and pre-recorded forms. This interface is out of scope for this 
release. 

Content distribution is carried out using either PSS or MBMS. In case of PSS, UGC is distributed by the PSS server. In 
case of MBMS, UGC is distributed via the BMSC.UPF. 

Distribution of user generated content to PSS and MBMS clients (receiving UEs) uses the same procedures for service 
provider discovery (clause 5), user service discovery (clause 6) and description retrieval (clause 7), streaming (clause 8) 
and download delivery as content that is provided in a different way. 



14 IVIBIVIS Download Service 

This section depicts the procedures for retrieval of missing parameters before session initiation in clause 14.1, the 
MBMS download session initiation, file repair and reception report procedures in clause 14.2, and session teardown 
procedure in clause 14.3. 

14.1 IVIissing parameters before session initiation 
14.1.1 Procedures at the UE 

If the UE does not have the all the information it needs to form an SDP offer, the UE shall send a SIP OPTIONS 

message. 

The "Request-URI" is related to the MBMS service that the user wants to activate. The "Request-URI" shall be 
composed of a user and domain part as defined as follows: 
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The user part contains the serviceld. 

The domain part is the Service Provider domain name, obtained from SSF. 

The TO header shall contain the same URI as in the "Request-URI" parameter. 

The FROM header shall indicate the public user identity of the user. 

Upon reception of the 200 OK including service access information encapsulated in multipart/MIME, the UE shall 
initiate MBMS download session as described in 14.2. 

14.1.2 Procedures at the SCF 

When receiving the SIP OPTIONS message, the SCF shall examine the serviceld present in the user-part of the TO 
header and lookup the requested User Service Description information. 

The SCF shall answer with the user service description information of the content delivery channel (encapsulated in 
multipart/MIME) as requested by the serviceld. 

14.2 MBMS Download Session Initiation, File Repair and Reception 
Report 

14.2.1 General (description 

Figure 3 1 gives an overview about the procedures for an IMS based MBMS Download Session initiation, File-Repair 
and reception report. 

If an associated delivery procedure description for File-Repair operations is available, then the UE receiver may use the 
File-Repair service as specified in [11] sub-clause 9.3. 

If an associated delivery procedure description for reception reporting is available, then the UE shall provide reception 
reports as specified in [11] sub-clause 9.4. 
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Figure 31 Procedures for IMS based MBMS Download 

Step 1, 2: The UE generates an initial SIP INVITE message sent to the SCF, indicating the chosen MBMS Download 
Service. A SDP offer is included in the SIP INVITE message. 

Step 3, 4: Upon receipt of SIP INVITE the SCF examine the SDP parameters in the SDP offer. In case of a successful 
examination, the SCF answers with a SIP 200 OK including the SDP answer. 

Step 5: The UE receives the MBMS download data using FLUTE. 
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Step 6: In case of incomplete download, file repair procedures are executed. 

Step 7, 8: The UE reports the reception statistics using either HTTP or SIP INFO message. 

1 4.2.2 Procedures at the UE 

The UE shall support the procedures specified in TS 24 229 [7] for originating sessions. 
The UE shall generate an initial INVITE request: 

• The Request-URI in the INVITE request shall be the well known PSI (Public Service Identifier) of the MBMS 
Download Service. 

• The To header shall contain the same URI as in the Request-URI. 

• The From header shall indicate the public user identity of the user. 

An SDP offer shall be included in the request. The SDP offer shall be done in accordance with the parameters received 
during UE service selection procedure and with media capabilities and required bandwidth available for the MBMS 
download service. The SDP offer shall include the following elements: 

• An a=source-filter line to indicate the IP source address of the FLUTE session. 

• An a=flute_tsi line to indicate Transport Session ID (TSI) of the FLUTE session. 
NOTE: The combination of the TSI and the IP source address identifies the FLUTE session. 

• The m-line(s) shall be set to the media parameters retrieved via service selection procedures for the requested 
MBMS download service. 

• The c-line(s) shall be set according to the multicast address retrieved via service selection procedures for the 
requested MBMS download service. 

The descriptions of above parameters conform to section 7.3 of 3GPP TS 26.346[1 1]. 

• An a=mbms_download_service:ServiceId line to indicate the MBMS download service which the UE intends to 

initiate. 

Once the UE receives the SIP response, the UE shall examine the FLUTE session parameters in the received SDP, and 
receive the MBMS download data accordingly. 

In case the FDT is unavailable, the UE shall get the FDT according to fdt_address attribute in the SDP Answer. The 
FDT contains content description information for the files delivered in the FLUTE session. 

In case of incomplete download, the UE shall execute the file repair procedures towards the repair server indicated by 
repair-server-address attribute in the SDP Answer. 

The UE shall report the reception statistics using either HTTP or SIP INFO message according to report-channel 
parameter of the SDP Answer. The XML contents in the report message refer to section 9.5.3.2 of 3GPP TS 26.346[11]. 

14.2.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

14.2.4 Procedures at the SCF 

The SCF shall support the procedures specified in TS 24.229 [7] applicable to an AS acting as a terminating UA. 

Upon receipt of SIP INVITE request, the SCF shall perform service authorization procedures to check the service rights 
of requested MBMS download service according to the user subscription information. See clause 10.4. 

The SCF shall examine the SDP parameters in the SDP offer. 
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• It shall examine the a=mbms_download_service parameter. This parameter contains the channel the UE 
intends to join. If the mbms_download_service parameter does not point to a channel that the UE is 
allowed to join the SCF shall not accept the offer and shall answer with a 403 error code. 

• It shall examine the c-line(s) to determine that it is a multicast session. It may also check that it corresponds to 
the mbms_download_service parameter. If not, the SCF shall answer with a 403 error code. 

If the SDP parameters are examined successfully, the SCF shall answer with a SIP 200 OK, indicating the SDP answer 
as follows: 

• The m-line(s) and c-line(s) shall be identical to ones indicated in the SDP offer. 

• The source-filter and flute_tsi attributes shall be identical to ones indicated in the SDP offer. 

• An a=fdt_address:uri to indicate the address of the File Delivery Table. 

• An a=repair-server-address:uri to indicate the address of the repair server. 

• An a=report-channel:SIP/HTTP line to indicate the UE that the reception report procedure should be performed 
by SIP or HTTP channel. 

• It shall include an a=recvonly attribute. 

1 4.2.5 Procedures at the BMSC.UPF 

The MBMS FLUTE session is already ongoing at the BMSC.UPF. No specific action is required. 

14.3 MBMS Download Session Teardown 



14.3.1 General Description 
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Figure 32: MBMS Download Session Termination 

Step 1:UE receives download content from the BM-SC.UPF. 

Step 2, 3: UE initiates a SIP BYE message to SCF, indicating which MBMS download session to close. 

Step 4, 5: SCF responds UE with a SIP 200 OK message when the SIP BYE is successfully handled and session 
terminated. At this stage, the UE can stop receiving the MBMS download session. 

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5. The deactivation is 
either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS Multicast Mode 
deactivation procedure (3GPP TS 23.246 [4]). 

1 4.3.2 Procedures at the UE 

The UE shall send a SIP BYE to the SCF. 

The UE may deactivate the according MBMS Bearer Service during steps 2 to 5 or after step 5 of clause 8.3.5.1. The 
deactivation is either according to the MBMS Broadcast Service deactivation (3GPP TS 23.246 [4]) or the MBMS 
Multicast Mode deactivation procedure (3GPP TS 23.246 [4]). 



£75/ 



3GPP TS 26.237 version 9.4.0 Release 9 



76 



ETSI TS 126 237 V9.4.0 (2010-10) 



1 4.3.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

1 4.3.4 Procedures at the SCF 

The SCF responds to the UE with a SIP 200 OK message after handling of the SIP BYE message. 

1 4.3.5 Procedures at the BMSC.UPF 

The BMSC.UPF is acting as described in 3GPP TS 23.246 [4]. 



15 PSS download service 
15.1 General Description 
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Figure 33: IMS based session set-up for progressive download 

1 . The UE initiates the progressive download session by sending SIP INVITE to the IM CN subsystem, 
including an SDP offer. 

2. The IM CN subsystem forwards the SIP INVITE message to the SCF. 

3. The SCF verifies the user rights for the requested content, selects a HTTP/SIP adapter, and forwards the 
SIP INVITE message to the HTTP/SIP adapter. 

4. The HTTP/SIP adapter selects a HTTP Server, and sends an HTTP POST message to the HTTP server, 
including the IP address of the UE. 
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5. The HTTP server answers to the HTTP/SIP adapter with a HTTP 200 OK response. 

6. The HTTP/SIP adapter sends the SIP 200 OK answer to the SCF, including download URL of the 
requested content file in the SDP answer. 

7. The SCF forward the SIP 200 OK to the IM CN subsystem. 

8. The IM CN subsystem forwards the SIP 200 OK to the UE. 

9. The UE sends HTTP request to the URL obtained from the SIP 200 OK message. 

1 0. The HTTP server delivers the content file in the HTTP response to the UE. 



1 5.2 Procedures at the UE 

The UE initiates the progressive download session by sending SIP INVITE to the IM CN subsystem. The content of the 
SIP INVITE shall be as follows: 

• The Request URI is related to the session the user wants to activate The Request-URI shall be composed of a 
user and domain part as defined as follows: 

The user part contains the content identifier, retrieved from user service description information from SSF 

The domain part is the Service Provider domain name, obtained from SSF. 

• The To header shall contain the same URI as in the Request URI. 

• The From header shall indicate the public user identity of the user. 

The content identifier shall be retrieved from service selection information. 

The other headers shall be set according to 24.229 [7]. 

An SDP offer shall be included in the initial INVITE request, in accordance with media capabilities and policies 
available for the PSS session and with the parameters received from the SSF during service selection procedure or 
during the procedure for retrieving missing parameters by SIP OPTIONS. 

The SDP media parameters should describe the HTTP progressive download session. The differences with the SDP 
offer defined for streaming is the absence of media line corresponding to the control protocol (RTSP), and the 
indication of TCP transport and HTTP progressive download method instead of streaming in "m" line. 

The SDP parameters for the HTTP progressive download channel shall be set as follows: 

• a 'm' line for an HTTP progressive download channel of format: m=<media> <port> <transport> <fmt> 

The media field shall have a value of "application". 

- The port field shall be set to a value of 9, which is the discard port. See RFC 4145 [13] and RFC 4572 [14]. 

The transport field shall be set to TCP or TCP/TLS. The former is used when HTTP runs directly on top of 
TCP and the latter is used when HTTP runs on top of TLS, which in turn runs on top of TCP. 

The <fmt> parameter shall be included and shall be set to 3gpp_http. 

NOTE: the 3gpp_http application format should have a new MIME subtype registered in IAN A. 

An "a=setup" attribute shall be present and set to "active" indicating that the UE will initiate an outgoing 
TCP connection to the HTTP Server. 

An "a= connection" attribute shall be present and set as "new" indicating that the UE will establish a new 
outgoing TCP connection towards the HTTP Server. 

A "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP 
address of the flow of the related HTTP progressive download channel (ex. c= IN I P4 < I P_ADDRESS>). 
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Optionally a "b=" line may contain the proposed bandwidth. If the user has fetched the bandwidth required 
for this particular content delivery channel during service selection retrieval, the bandwidth attribute at media 
level shall be set to this value. Otherwise, this attribute shall be set to a pre-configured value; 
(ex. b=AS: 15000) 

An example of the SDP offer for IMS-based PSS progressive download is: 

v=0 

o=bob 2890844527 2890844527 IN IP4 192.0.2.2 

s=Download Session 

i=A download session declared within the session description protocol 

t = 

m=application 9 TCP 3gpp_http 

a=connection : new 

a=setup : active 

c= IN IP4 192 .0.2.2 

b=AS: 15000 

Once the UE has received the SIP 200 OK from the HTTP/SIP adapter, it sends the HTTP GET request to the URL 
obtained in download session description. The HTTP 'Connection' header shall be set to 'Keep- Alive' to require 
persistent TCP connection. 

An example of the HTTP GET request sent by the UE is: 

HTTP GET http://123.23.23.23/ moviel.mpeg 

1 5.3 Procedures at the IM CN subsystem 

The IM CN subsystem shall forward the SIP INVITE to the SCF. 

Upon reception of the SIP 200 OK from the SCF, the IM CN subsystem forwards the SIP 200 OK to the UE. 

The IM CN Subsystem handles the SIP dialog as defined in 3GPP TS 23.228 [6]. 

1 5.4 Procedures at the SCF 

Upon reception of the SIP INVITE from the UE, the SCF checks the user rights for the requested content, identifies that 
the request is for progressive download, selects and forwards the SIP request to the HTTP/SIP adapter which is in 
charge of the download service by changing the "Request-URI" accordingly. 

When receiving a 301 or 302 response from the HTTP/SIP adapter, the SCF shall not forward this message to the UE. 

1 5.5 Procedures at the HTTP/SIP adapter 

Upon reception of the download session initiation request, the HTTP/SIP adapter shall examine the content identifier 
present in the user-part of the To header and the media parameters in the SDP, selects a HTTP Server according to the 
Request URI, and sends a HTTP POST message to the HTTP server including the IP address of the UE. 

The HTTP/SIP adapter may decide to redirect the request to another HTTP/SIP adapter server. In this case the 
HTTP/SIP adapter shall return a 301 response if the content is not managed by this HTTP/SIP adapter or 302 response 
for any other reasons (e.g. load balancing). The redirecting HTTP/SIP adapter indicates one or more destination 
HTTP/SIP adapter addresses in the Contact header. 

The HTTP/SIP adapter returns the SIP 200 OK message to the SCF, including the SDP answer. The SDP answer should 
describe the HTTP progressive download session. The differences with the SDP answer defined for streaming is the 
absence of media line corresponding to the control protocol (RTSP), the indication of TCP transport and HTTP 
progressive download method instead of streaming in "m" line, the indication of HTTP URL instead of RTSP URI. 

If the content that the user has selected cannot be found the HTTP/SIP adapter shall reply with appropriate, SIP error 
code 404 Not Found response. 

The HTTP/SIP adapter shall construct the SIP 200 OK message as follows: 
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• an 'm' line for an HTTP progressive download channel of format: m=<media> <port> <transport> <fmt> 

— The media field shall have a value of "application". 

— The port field shall be set to the value of HTTP Server for the progressive download channel, such as 80. 

— The transport field shall be set to TCP or TCP/TLS. The former is used when HTTP runs directly on top of 
TCP and the latter is used when HTTP runs on top of TLS, which in turn runs on top of TCP. 

— The fmt field shall be identical to the one received in the SDP offer. 

• a "c" line shall include the network type with the value set to IN, the address type set to IP4 or IP6 and IP address 
of HTTP Server for the flow of the related HTTP progressive download channel (e.g. c = IN I P4 
<IP_ADDRESS>). 

• The "a=setup" attribute shall be present and set to 'passive' indicating that connection shall be initiated by the other 
endpoint (UE). 

• An "a= connection" attribute shall be present and set as "new" indicating that the UE will establish a new outgoing 
TCP connection towards the HTTP Server. 

• One or more a=fmtp lines representing HTTP specific attributes set as follows: 

a "fmtp:3gpp_http http-url" attribute in the format of an absolute URI to be used for the UE in the 
subsequent HTTP requests. The h-uri can be in form of absolute or relative URI. If absolute URI is 
specified then it is used as-is in subsequent HTTP requests. If relative URI is specified in form of a 
media path, then the HTTP absolute URI could be constructed by the UE using the IP Address (from c- 
line) and port (from m-line) as the base followed by h-uri value for the content path. 

• the "b=" line shall contain the proposed bandwidth. Since the content download is unidirectional the bandwidth 
shall be set to 0. ( ex . b=AS:0). 

An example of the SDP answer in the SIP 200 OK response is: 

v=0 

o=bob 2890844527 2890844527 IN IP4 192.0.2.1 

s=Download Session 

i=A download session declared within the session description protocol 

t = 

m=application 80 TCP 3gpp_http 

a=connection : new 

a=setup ipassive 

a=fmtp 3gpp_http h-url http://operator.com/moviel.mpeg 

c=IN IP4 192.0.2.1 

b=AS : 

1 5.6 Procedures at the HTTP server 

Upon reception of the HTTP POST message received from the HTTP/SIP adapter, the HTTP server answers with an 
HTTP 200 OK message to the HTTP/SIP adapter. 

Upon reception of the HTTP GET received from the UE, the HTTP server delivers in the HTTP response the content 
file corresponding to the URL obtained in the received HTTP GET. The HTTP 'Connection' header shall be set to 
'Keep-Alive' to indicate it is a persistent TCP connection. 
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15.7 Session termination 

15.7.1 General description 

15.7.1.1 UE-initiated PSS download session teardown 
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Figure 33a: UE-initiated IIVIS PSS download session termination 

Here the case of UE termination is described. The following steps are carried out: 

1. The UE sends a SIP BYE message. 

2. The IM CN subsystem forwards the SIP BYE message to the SCF. 

3. The SCF sends the SIP BYE message to the HTTP/SIP adapter. 

4. The HTTP/SIP adapter sends an HTTP POST to the HTTP server. 

5. In case the HTTP Server is transmitting the content file, it stops sending data for this session. The HTTP 
server sends a HTTP 200 OK to the HTTP/SIP adapter. 

6. The HTTP/SIP adapter sends a SIP 200 OK to the UE via SCF and IM CN subsystem. 
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15.7.1 .2 SCF-initiated PSS download session teardown 
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Figure 33b: SCF-initiated IIVIS PSS download session termination 

Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out: 

1) The SCF sends a SIP BYE to the HTTP/SIP adapter. 

2) The HTTP/SIP adapter sends HTTP POST message to the HTTP server. 

3) The HTTP server sends the HTTP 200 OK message to the HTTP/SIP adapter. 

4) The HTTP/SIP adapter sends the SIP 200 OK message to the SCF. 

5) Upon receipt of the SIP 200 OK, the SCF sends the SIP BYE message to the IM CN subsystem. 

6) The IM CN Subsystem forwards the SIP BYE message to the UE. 

7) The UE sends a SIP 200 OK message to the IM CN Subsystem. 

8) The IM CN Subsystem forwards the SIP 200 OK to the SCF. 
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15.7.1 .3 HTTP/SIP adapter-initiated PSS download session teardown 
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Figure 33c: HTTP/SIP adpater-initiated IMS based session teardown for PSS download 

Here the case of the SCF-initiated teardown procedure is described. The following steps are carried out: 

1) The HTTP/SIP adapter sends the HTTP POST to the HTTP server. 

2) The HTTP server sends the HTTP 200 OK to the HTTP/SIP adapter. 

3) The HTTP/SIP adapter sends the SIP BYE message to the SCF. 

4) The SCF sends the SIP 200 OK message to the HTTP/SIP adapter. 

5) The SCF sends the SIP BYE message to the IM CN Subsystem. 

6) The IM CN Subsystem forwards the SIP BYE message to the UE. 

7) The UE sends a SIP 200 OK message to the IM CN Subsystem. 

8) The IM CN subsystem forwards the SIP 200 OK message to the SCF. 

1 5.7.2 Procedures at the UE 

15.7.2.1 UE-initiated PSS download session teardown 

To teardown the PSS download session, the UE shall send a SIP BYE message to the SCF. 

15.7.2.2 Network-initiated PSS download session teardown 

Upon receipt of the SIP BYE message, the UE shall the SIP 200 OK message to the SCF. The UE procedes to release 
the associated resources held for the PSS session. 

15.7.3 Procedures at the IM CN Subsystem 

The IM CN subsystem handles the SIP dialog as defined in [6]. 
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15.7.4 Procedures at the SCF 

15.7.4.1 UE-initiated PSS download session teardown 

Upon receipt of a SIP BYE message the SCF shall forward it to the HTTP/SIP adapter. 

15.7.4.2 SCF-initiated PSS download session teardown 

The SCF initiates the PSS download session teardown by sending a SIP BYE message to theHTTP/SIP adapter. Upon 
receipt of the SIP 200 OK from the HTTP/SIP adapter, the SCF shall send a SIP BYE message to the UE. 

15.7.4.3 HTTP/SIP adapter-initiated PSS download session teardown 

Upon receipt of the SIP BYE message received from the HTTP/SIP adapter, the SCF sends the SIP 200 OK message to 
the HTTP/SIP adapter. Then the SCF forwards the SIP BYE message to the UE. 

15.7.5 Procedures at the HTTP/SIP adapter 

15.7.5.1 UE-initiated PSS download session teardown 

Upon receipt of a SIP BYE message from the SCF the HTTP/SIP adapter shall send a HTTP POST message to the 
HTTP Server. 

Upon receipt of a HTTP 200 OK message from the HTTP server, the HTTP adapter shall send a SIP 200 OK message 
to the SCF. 

15.7.5.2 SCF-initiated PSS download session teardown 

Upon receipt of the SIP BYE message, the HTTP/SIP adapter sends the HTTP POST message to the HTTP server. 
Upon receipt of the HTTP 200 OK message from the HTTP server, the HTTP/SIP adapter sends the SIP 200 OK to the 
SCF. 

15.7.5.3 HTTP/SIP adapter-initiated PSS download session teardown 

The HTTP/SIP adapter sends the HTTP POST to the HTTP server. Upon receipt of the HTTP 200 OK, the HTTP/SIP 
adapter sends the SIP BYE messge to the SCF. 

15.7.6 Procedures at the HTTP server 

Upon receipt of a HTTP POST from the HTTP/SIP adapter, the HTTP server shall stop still on-going data transmissions 
and send a HTTP 200 OK message to the HTTP/SIP adapter. 



16 Inter UE Session Transfer 



Inter UE Session transfer (lUT) is used for the transfer of an ongoing PSS session from a transferor UE (UE-1) to a 
transferee UE (UE-2). lUT includes the transfer of the session control as well as the media flows. 

UE-1 and UE-2 are under the same user subscription and are served by the same SCF. 

Inter UE Session transfer follows the general Inter UE session transfer procedures as defined in [40] and [41]. 

NOTE 1: Functionality of SCC AS [40] for Inter UE transfer can be implemented by the SCF. 

In the push mode, the session transfer is initiated by UE-1. 

NOTE 2: In the pull mode, the session transfer is initiated by UE-2. Pull mode is not in the scope of Rel-9 and will 
be handled in a later Release. 
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16.1 Push mode 

UE-l is involved in an IMS session with the PSS server. The information flow in Figure 34 shows the transfer of the 
session from UE-l to UE-2. The grey boxes refer to the session transfer procedures as defined in clause 15 of [41]. 
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Figure 34: Inter UE session transfer. 

Note: This sequence is simplified and does not e.g. show session progress messages 

1.-2. UE-1 is in a IMS controlled PSS session with PSS server receiving a media stream. 

3. UE-1 may initiate nBookmark procedure according to clause 12.1 

4.-5. SIP REFER request initiating the inter UE transfer to UE-2 is sent from UE-1 to SCC 

The SIP REFER request shall follow the procedures in [41] section 15. 

Additionally, the Refer-To header shall be extended by a To header field which includes the original content 
identifier copied from the Request URI of the original SIP INVITE request initiated from the transferor. 

Further a body header that contains the SDP body to be included in the PSS session initiation request initiated 
from the transferee UE. The SDP body shall contain the same number of media lines as the SDP used in the 
original PSS session from the transferor. Each media line shall indicate the same media type as its corresponding 
media component in the SDP used in the original session by the transferor UE. 
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The body of the REFER request shall include the bookmark as defined in Annex J. 

If step 3 is carried out, the bookmark may be not present. In this case, an identifier of the stored bookmark is 
included. 

NOTE: Before initiation of lUT, UE 1 may discover UE-2, e.g. by presence service, which is out of scope of TS 

26.237. 

6. The sec authorizes the request and if authorization is passed successfully, the SCC forwards the SIP REFER 
request further. 

7.-8. SIP REFER request (SCC to UE-2). 

9.-12. SIP 202 response to the SIP REFER request (UE-2 to UE-1). 

13. PSS session initiation using the bookmark according to clause 12.2.2. 

14. UE-2 is in a IMS controlled PSS session with PSS server. 

The media path is now established between UE-2 and PSS server and the IMS service control between UE-2 and 
SCC AS. 

15.-18.SIP NOTIFY request (UE-2 to UE-1 over intermediate IM CN subsystem entities and SCC). 

The UE-2 generates the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-1. 

19.-22. SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem 
entities and SCC). 

23. PSS session teardown between UE-1 and PSS server according to clause 8.2.6.1.1. 
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Annex A (normative): 
3gpp_rtsp application 



The 3gpp_rtsp application defines a set of RTSP parameters. An RTSP parameter is included in "a=fmtp" line of the 
SDP and is expressed in the form of parameter=value. 

a=fmtp : 3gpp_rtsp <parameter name>=<value> 

The "version" parameter sets the "version-number" representing the version of RTSP that will be used in the RTSP 
media stream. The version number shall be "1.0" in this version of the specification. The RTSP version shall be 
included in all SDP offers and answers. The same version shall be used by all entities. 

a=fmtp : 3gpp_rtsp version=<version-number> 

To exchange RTSP header fields within the SIP offer/answer, the RTSP media stream allows for attributes with the 
following format: 

a=fmtp : 3gpp_rtsp h-<header- name >=<header- value >, 

where "header-name" is the name of the RTSP header field being described and "header-value" is the value of the RTSP 
header field. The value of the header-name is case insensitive. The value of the header- value is interpreted according to 
the rules of RTSP. The list of authorized headers in the SIP offer/answer is as follows: 

• Session: this is the RTSP session id as established by the PSS adapter to be used for further RTSP transactions. 

• Offset: this is a range value to be used in the first PLAY request by the UE. 

• Supported" header filed with the following feature tags (see 3GPP TS 26.234 [8]): 

"3gpp-switch" feature-tag, clause 5.5.4.2. 
"3gpp-switch-req-sdp" feature-tag, clause 5.5.4.3. 
"3gpp-switch-stream" feature-tag, clause 5.5.4.4. 

• Require (see 3GPP TS 26.234 [8]). 

• Pipelined-Requests (see 3GPP TS 26.234 [8]). 

• 3GPP-Adaptation (see 3GPP TS 26.234 [8]). 

UE, PSS Servers and PSS adapters shall support all these headers and feature tags. 



£75/ 



3GPP TS 26.237 version 9.4.0 Release 9 87 ETSI TS 1 26 237 V9.4.0 (201 0-1 0) 



Annex B (informative): 
Examples 

Void (TBD). 
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Annex C (normative): 
Void 
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Annex D (normative): 

XML Schema for PSS and MBMS commands 

<?xml version="l. 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 1/XMLSchema" 

xmlns :pss="urn:org: etsi :ngn:params :xml : ns : PssContentSwitchData" 

xmlns :mbms="urn:org: etsi mgmparams :xml :ns :MbmsContentSwitchData" 

xmlns : local="urn:org: etsi mgmparams :xml :ns : PssMbmscommand" 

targetNamespace="urn:org: etsi mgmparams :xml ms : PssMbmscommand" elementFormDefault = " qualified" 

attributeFormDefault= "unqualified" > 

<xs : import namespace="urmorg: etsi mgmparams :xml ms : PssContentSwitchData" 
schemaLocation="PssSwitchData .xsd"/> 

<xs : import namespace="urn: org : etsi mgmparams :xml ms iMbmsContentSwitchData" 
schemaLocation="MbmsSwitchData .xsd"/> 

<xs : element name="ImsPssMbmsCommand" > 
<xs : complexType> 
<xs : choice> 

<xs:element name="PssSwitch" type="local : tPssSwitch" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

<xs: element name="MbmsSwitch" type= " local : tMbmsSwitch" minOccurs=" 0" 
maxOccur s = " unbounded " / > 
</xs : choice> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="tPssSwitch" > 
<xs : choice> 

<xs : element ref ="pss : PssSwitchData"/> 
</xs : choice> 
</xs : complexType> 

<xs : complexType name=" tMbmsSwitch" > 
<xs : choice> 

<xs : element ref ="mbms :MbmsSwitchData"/> 
</xs : choice> 
</xs : complexType> 
</xs : schema> 
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Annex E (normative): 

XML Schemas for the PSS content switch data 

This annex specifies XML schemas for PSS content switch data: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2001/XMLSchema" 

xmlns="urn:org: etsi :ngn:params :xml :ns : PssContentSwitchData" 

targetNamespace="urn:org: etsi :ngn:params :xml :ns : PssContentSwitchData" elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : element name="PssSwitchData" > 

<xs : complexType> 
<xs : sequence> 
<xs:element name="ContentID" type="xs : string" minOccurs="0"/> 
<xs:element name="DateTime" type="xs idateTime" minOccurs=" 0"/> 
<xs:element name=" Extension" type="tExtension" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence > 
</xs : complexType> 
</xs : element > 

<xs : complexType name="tExtension" > 
<xs : sequence> 
<xs : any processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 
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Annex F (normative): XML Schemas for the MBMS content 
switch data 

This annex specifies XML schemas for MBMS content switch data: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn:org: etsi :ngn:params :xml :ns iMbmsContentSwitchData" 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn:org: etsi :ngn:params :xml :ns iMbmsContentSwitchData" 
elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 
<xs : element name="MbmsSwitchData" > 
<xs : complexType> 

<xs : sequence> 

<xs: element name="ServiceId" type="xs : string" minOccurs="0"/> 
<xs: element name="ProgrammeId" type="xs : string" minOccurs="0"/> 
<xs:element name="DateTime" type="xs :dateTime" minOccurs="0"/> 
<xs: element name=" Extension" type="tExtension" minOccurs=" 0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element> 

<xs : complexType name="tExtension" > 
<xs : sequence> 
<xs : any processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType > 
</xs : schema> 
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Annex G (normative): 

XML Schema for PSS and MBMS UE Device Capabilities 

This XML Schema defines the UE device capabilities that are signalled by the UE within the body of the SIP 
SUBSCRIBE request when attaching to the service. Another document is also part of the body to describe PSS 
Capabilities as defined in TS 26.234. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema 

targetNamespace="urn:3GPP:metadata:2008 : IMS -PSS -MBMS lUECap" 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

elementFormDefault=" qualified" attributeFormDefault= "unqualified" > 

<xs : annotation> 

<xs : documentation xml : lang="en"> 
Defines the capabilities of the UE that is currently associated with the user 
</xs : documentation> 
</xs : annotation> 

<xs:element name="UEInformation" type="tUEProf ile"/> 
<xs : complexType name="tUEProf ile" > 
<xs : sequence> 

<xs: element name="UserEquipmentModelName" type="xs : string"/> 
<xs : element name="UserEquipmentModelVersion" type="xs : string"/> 
<xs:element name="UserEquipmentID" type=" tUEID"/> 

<xs : element name ="UserEquipment Class" type="tUserEquipmentClass"/> 
<xs : element name="UserEquipmentMBMSCapable" type="xs : boolean" /> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="tUEID" final="list restriction" > 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >User Equipment ID</label> 
<definition xml : lang="en" >Unique Identifier for the UE{eg;Could be MAC address of UE) 
</def inition> 

</xs : documentation> 
</xs : annotation> 

<xs : restriction base="xs : string" > 
<xs iminLength value="0"/> 
<xs imaxLength value="16"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name="tUserEquipmentClass" final="list restriction" > 
<xs : annotation> 

<xs : documentation> 

<label xml : lang="en" >User Equipment class</label> 
<definition xml : lang="en" >Specif ies the type of UE</def inition> 

</xs : documentation> 
</xs : annotation> 
<xs : restriction base="xs : string" > 

<xs : enumeration value="STB"> </xs : enumeration> 

<xs : enumeration value="PC"> </xs : enumeration> 

<xs : enumeration value="Handset" > </xs : enumeration> 
</xs :restriction> 
</xs : simpleType> 
</xs : schema> 
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Annex H (normative): 

XML Schema for Service Attachment Information 

This annex describes the XML schema for the service attachment information to be returned to UE by SDF. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 001/XMLSchema" elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs: element name="SSF" type="tSSF"> 

<xs : annotation> 

<xs :documentation>XML Body of the SDF SIP Notify Response</xs : documentation> 

</xs : annotation> 
</xs : element> 

<xs : complexType name="tSSF"> 
<xs : sequence> 

<xs:element name="Description" type="tMultilingual" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

<xs: element name="ServiceProvider" type="tSSFServiceProvider" minOccurs=" 0"/> 
<xs:element name="Pull" type="tSSFPull" minOccurs="0" maxOccurs= "unbounded" /> 
<xs:element name="Push" type="tSSFPush" minOccurs="0" maxOccurs="unbounded"/> 
<xs:element name="MBMSSecurityProcedure" type="tMBMSSec" minOccurs="0"/> 
<xs:element name=" Extension" type="tExtension" minOccurs="0"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="ID" type="tHexadecimall6bit" use="required"/> 
<xs : attribute name=" Technology" type="xs : string" use="required"/> 
<xs : attribute name= "Version" type="tVersion" > 
<xs : annotation> 

<xs :documentation>The version number is incremented when one or more attributes of 
the SSF element have changed, so that the receiver knows whether it should update its data or 
not . </xs : documentation> 

</xs : annotation> 
</xs : attribute> 

<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType> 

<xs : simpleType name="tVersion" > 

<xs : restriction base="xs : integer" > 
<xs :minlnclusive value="0"/> 
<xs :maxlnclusive value="255"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="tSSFServiceProvider" > 
<xs : sequence> 

<xs:element name="Name" type="tMultilingual" maxOccurs="unbounded"/> 
<xs:element name="Description" type="tMultilingual" minOccurs="0" 
maxOccur s = " unbounded " / > 

<xs:element name=" Extension" type="tExtension" minOccurs=" 0"/> 
</xs : sequence> 

<xs : attribute name="DomainName" type="tDomain" use= " required" > 
<xs : annotation> 

<xs :documentation>It is recommended that the DomainName complies with the "preferred 
name syntax" of RFC1034 clause 3 . 5</xs :documentation> 
</xs : annotation> 
</xs : attribute> 

<xs : attribute name="LogoURI" type="xs : anyURI" use="optional"/> 
<xs : anyAttribute namespace="##other" processContents="lax"/> 
</xs : complexType > 

<xs : simpleType name="tDomain" > 

<xs : restriction base="xs : string" > 

<xs: pattern value=" {{. |\n|\r)*)?{\. {. |\n|\r)*)+"/> 

</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="tSSFPull" > 
<xs : complexContent> 

<xs : extension base="tDataTypeList" > 

<xs : attribute name="Location" type="xs : anyURI" use="required"/> 
<xs : anyAttribute namespace="##other" processContents="lax" > 
<xs : annotation> 



£75/ 



3GPP TS 26.237 version 9.4.0 Release 9 94 ETSI TS 1 26 237 V9.4.0 (201 0-1 0) 

<xs :documentation>Extension attribute to define further 
data</xs : documentation> 

</xs : annotation> 
</xs : anyAttribute> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 

<xs : complexType name="tSSFPush" > 
<xs : complexContent> 

<xs : extension base="tDataTypeList" > 

<xs : attribute name="IpVersion" type="tVersion" use="optional"/> 
<xs : attribute name="MulticastAddress" type="xs : string" use="required"/> 
<xs : attribute name="MulticastPort" type="xs lunsignedShort" use=" required" /> 
<xs : attribute name="SourceAddress" type="xs : string" use="optional"/> 
<xs : anyAttribute namespace="##other" processContents="lax" > 
<xs : annotation> 

<xs :documentation> Extension attribute to define further data 
></xs : documentation> 

</xs : annotation> 
</xs : anyAttribute > 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 

<xs : complexType name="tDataTypeList" > 
<xs : sequence maxOccurs="unbounded" > 
<xs: element name="DataType" > 
<xs : complexType > 

<xs : sequence minOccurs="0" maxOccurs= "unbounded" > 
<xs: element name= " Segment " > 
<xs : annotation> 

<xs :documentation>Segments are used to logically separate Service 
Selection inf ormation</xs : documentation> 

</xs : annotation> 
<xs : complexType> 

<xs : attribute name="ID" type="tHexadecimall6bit" use="required"/> 
<xs : attribute name= "Version" type="tVersion" use="optional"/> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 

<xs : attribute name="Type" type="tHexadecimal8bit" use="required" > 
<xs : annotation> 

<xs :documentation> Specify the type of Service Selection Information 
that is delivered by the SSF 

</xs : documentation> 

</xs : annotation> 
</xs : attribute> 
</xs : complexType> 
</xs : element> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="tExtension" > 

<xs : sequence> 

<xs : any processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 

</xs : sequence> 
</xs : complexType> 

<xs : complexType name="tMultilingual" > 
<xs : simpleContent> 

<xs : extension base="xs : string" > 

<xs : attribute name=" Language" type="tLanguage" use="required"/> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType > 

<xs : simpleType name="tLanguage" > 

<xs : restriction base="xs : string" > 
<xs : annotation> 

<xs : documentation> 

<definition xml : lang="en" >ISO 639-2 Language code</def inition> 
</xs : documentation> 
</xs : annotation> 
<xs iminLength value="3"/> 
<xs imaxLength value="3"/> 
</xs : restriction> 
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</xs : simpleType> 

<xs : simpleType name="tHexadecimal8bit" > 
<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-9a-fA-F] {l,2}"/> 
</xs : restriction> 

</xs : simpleType> 

<xs : simpleType name="tHexadecimall6bit" > 
<xs : restriction base="xs : string" > 

<xs:pattern value=" [0-9a-fA-F] {l,4}"/> 
</xs : restriction> 

</xs : simpleType> 

<xs : simpleType name="tMBMSSec" > 

<xs : restriction base="xs : string" > 
<xs : enumeration value="SIP"/> 
<xs : enumeration value="HTTP"/> 
</xs : restriction> 
</xs : simpleType> 

</xs : schema> 
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Annex I (normative): 

XML Schemas for SIP based MBMS security procedures 

1.1 Bootstrapping transaction identifier 

The following specifies XML schema for the bootstrapping transaction identifier to be sent within the body of SIP (re- 
)INVITE from the UE to the SCF. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 1/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2 005 :MBMS ibootstrappingTransactionldentif ier" 
elementFormDefault= "qualified" attributeFormDefault=" unqualified" > 
<xs : element name="mbmsAuthorizedSecurityRegister" > 
<xs : annotation> 

<xs :documentation>MBMS Security Registration according to TS 26 . 237</xs :documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="btid" type="xs : string" maxOccurs="unbounded" minOccurs="l"/> 
<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" 
processContents= " lax" /> 
</xs : sequence> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element> 
</xs : schema> 



1.2 NAF key information 



The following specifies XML schema for the UE and NAF key related information to be sent within the body of HTTP 
request from the SCF to the BM-SC. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.wS . org/2 001/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS mafKeylnfo" 
elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 
<xs : element name="mbmsAuthorizedSecurityRegister" > 
<xs : annotation> 

<xs :documentation> SIP based MBMS Security Registration according to TS 
26 . 237</xs : documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="ueIPaddress" type="xs : anyURI" maxOccurs="unbounded" 
minOccurs=" 0"/> 

<xs:element name="muk" type="xs : anyURI" maxOccurs="unbounded" minOccurs="l"/> 
<xs:element name="mukLif eTime " type="xs : anyURI" maxOccurs="unbounded" 
minOccurs= " 1 " / > 

<xs:element name="btid" type="xs : string" maxOccurs="unbounded" minOccurs="l"/> 
<xs:element name="naf Fqdn" type="xs :base64Binary" maxOccurs="unbounded" 
minOccurs= " 1 " / > 

<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" 
processContents="lax"/> 
</xs : sequence > 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element > 
</xs : schema> 
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Annex J (normative): 

XML Schema for nBookmark 

This section defines the XML schema and its syntax for networked bookmark. 



J.1 XML Schema 



<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 001/XMLSchema" elementFormDefault=" qualified" 
attributeFormDefault=" unqualified" targetNamespace="urn: 3gpp : bookmark: 2009 : IMS-PSS-MBMS" xmlns : tns= 
urn:3gpp : bookmark: 2009 : IMS-PSS-MBMS " xmlns :bcast="urn : oma :xml : beast : sg: fragments : 1 . 0" > 
<xs : import namespace="urn:oma :xml : beast : sg: fragments : 1 . 0" schemaLocat ion=" imports /OMA- SUP - 
XSD_bcast_sg_fragments-Vl_0-2 0090212-A.xsd"/> 
<xs : element name="BookmarkList"> 
<xs : complexType> 
<xs : sequence> 

<xs:element name=" Bookmark" type="tns :BookmarkType" minOccurs="0" 
maxOccur s = " unbounded " / > 

</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="BookmarkType" > 
<xs : sequence> 

<xs: element name=" Creator" type="xs : anyURI"/> 
<xs:element name=" Created" type="xs :dateTime"/> 
<xs :choice> 

<xs : element name="PSSProgramId" type= "beast :globalContentID"/> 
<xs : element name="MBMSProgramId" type= "beast :globalContentID"/> 
</xs :ehoiee> 

<xs:element name="Of f set" type="xs : duration" /> 
<xs:element name="Tag" type="xs : string" minOeeurs="0"/> 
<xs:element name="Rank" type="xs : string" minOeeurs="0"/> 
<xs:element name=" Comment" type="xs : string" minOeeurs="0"/> 
<xs:element name=" Expires" type="xs :dateTime" minOeeurs=" 0"/> 
<xs: element name=" Sharing" type="xs : boolean" /> 

<xs:element name="RetrievalCount" type="xs :nonNegativeInteger" minOeeurs=" 0"/> 
<xs:element name="RetrievalTime" type="xs :dateTime" minOeeurs=" 0" 
maxOeeur s = " unbounded " / > 
</xs : sequenee> 

<xs : attribute name="id" type="xs : anyURI" use=" required" /> 
</xs : eomplexType> 

</xs : sehema> 



J. 2 Syntax 

This section provides the syntax for the above XML schema. 
The following elements SHALL be provisioned by the UE: 

• Creator: Represents the user who creates the bookmark, it shall be in the format of IMPU. 

• Created: Represents the time when the bookmark is created. 

• PSSProgramId: Represents the id of the bookmarked program, which shall be globalContentID retrieved 
from User Service Description. 

• MBMSProgramId: Represents the id of the bookmarked program, which shall be globalContentID 
retrieved from User Service Description. 

• Offset: Represents the bookmark time, in the format of an offset from the beginning of the program. 

• Comment: Represents any comment chosen by the user. 
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• Tag: Represents any categorization chosen by the user 

• Rank: Represents the user favorite rating for the bookmark 

• Sharing: If set, the bookmark can be shared with others. 

The following elements SHALL be provisioned by the SCF: 

• Retrieval count: SHALL be set to and incremented by the service provider when the bookmark is 
retrieved. 

• Expires: Represents the expire time of current bookmark; 

• Id: Represents the identifier of current bookmark; 
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